Adding Identity without Password?

[ramriot]

@ramriot, I don't know where you got the idea for an "unencrypted export" from, but afaik, there is no such thing - neither in the spec, nor in any client implementation I've come across.

In the S4 storage format (which is used for export/import as well, only with varying block types present) ALL key material will ALWAYS be encrypted, either under the users master password or the rescue code.

So I don't really understand what you're getting at here. Am I missing something?

I gave all possible options, only some of which are called upon in the spec & I also differentiated by key type what I think are the handling requirements and inherent risks. Thank you for illuminating your observations of that, but if what you just said above is true then I need to reread the spec because I can see some serious security issues in your description & some of those in previous posts, which was my reason for speaking up.

 

[PHolder]

I fear you're letting perfect be the enemy of good enough. There needs to be a way to securely transmit an identity into a new device. There are two options. One is to use the day to day password, which should most likely mean both devices will have the same password in the end. The rescue code, as I understand it, is barely much more than a stronger password. (On the assumption that most people won't use a password near as long as the rescue code for day to day operation. That may not be a valid assumption, as my own SQRL password is greater than 20 characters with mixed upper/lower/numbers/punctuation.) So far as I know, the rescue code also encrypts the key necessary to compute the VUK for a given SUK.

I guess the clear question is whether you need an inter-device communication of identity information that is different than the backup options. I could envision an approach where the holder of an identity is told to prepare for sharing, and it computes a special packet of info, potentially as a QR code, and generates a one time password for that transfer. If you knew you were doing the transmission in secure privacy, then you could show this on the screen while the import is completed. This would mandate you supply a new password, which you would potentially make identical to the old one, and then would re-encrypt everything for that identity on this new device. It could even offer the option to NOT include the block with the rescue code, which would make that device fully limited (in the fear it might become lost or stolen or used against you somehow.)

 

[ramriot]

I fear you're letting perfect be the enemy of good enough. There needs to be a way to securely transmit an identity into a new device. There are two options. One is to use the day to day password, which should most likely mean both devices will have the same password in the end. The rescue code, as I understand it, is barely much more than a stronger password. (On the assumption that most people won't use a password near as long as the rescue code for day to day operation. That may not be a valid assumption, as my own SQRL password is greater than 20 characters with mixed upper/lower/numbers/punctuation.) So far as I know, the rescue code also encrypts the key necessary to compute the VUK for a given SUK.

I believe you are wrong in your assumptions then, from what I can glene the Rescue_Code is used to encrypt the IUK from which the IMK is deterministically derived. The IMK is then encrypted with a user provided passphrase, if that holds the all that follows is true.

If an attacker gets your IMK then it is possible for you to re-key your identity ( migrate to a new IUK->IMK via the ability to satisfy VUK/SUK challenges & mark the prior IUK as revoked into the PIUK).

If though an attacker gets your IUK then its GAME OVER, GO HOME. You will have lost control as the attacker can now re-key your identity & there is not in rpotocol way for you to gain back access to your online assets, you will need to call customer support :-(

Lets say your trust in the device you generated your SQRL identity on is warranted (if it was not then we are already owned), now say you want to sync that identity to a new device. If you do that & give the new device your user password then should that device have been already compromised of the given passphrase not be wiped after use or some other mistake made your exposure is recoverable because only the IMK is leaked.

If though you sync to a new device and give it the Rescue_Code to complete the action you expose the IUK to this new potentially less trusted device.

I believe that "letting perfect be the enemy of good" is a good motto but blithely performing unrecoverable risky actions on possibly multiple devices opens the trust zone way beyond what is reasonable.

I do believe that regular users should never be using the Rescue_Code for more than rekeying an identity on a known trusted device & it would be remiss of us as programmers to offer them the option without making it VERY clear to them of the risks.