Adding Identity without Password?

[Brian Buchanan]

With Steve's app I can import an Identity without entering the password until it's needed. Having the same functionality here would make importing an identity quicker. It would also allow the identity to use the Rescue Code if the password was forgotten.

 

[PHolder]

import an Identity without entering the password

I'm unsure what you're referring to here, but I think you are mistaken.

You can "import" outside the app by copying the identity file into the correct folder. Inside the app, you need to have either the rescue code or the password.

 

[ahauser]

Please note that having to use the password when importing an identity into a different client is by design. This is because each client should honor the "password verify seconds" identity setting, which is only possible when decrypting the identity with the identity's current enScrypt settings and then re-encrypting it, determining the correct scrypt iteration count for the current device "on the fly" to accomodate for the password verification time set in the identity.

Otherwise, an identity created on a super powerful computer could take ages on a low-end smartphone to decrypt and vice-versa.

//EDIT:
This is a quote from https://www.grc.com/sqrl/SQRL_Cryptography.pdf, page 21:

Operational Note: This SQRL identity database bundles the GRC SQRL client user's user-interface preferences, including the time required to process a full password input. When this identity is imported into a compatible client running on a platform having a different processing speed - either a different PC or a mobile device - that SQRL client will obtain that user's preferred password processing time. Although different environments (for example, mobile) might suggest a differing security posture and password processing overhead, the client can note when a large difference exists between the processing time of the origin device - as revealed in the bundled time specification - and the current platform. The client can offer to immediately re-encrypt the user's just entered password to re-normalize all future password processing time.

 

[Jeffa]

Please note that having to use the password when importing an identity into a different client is by design. This is because each client should honor the "password verify seconds" identity setting, which is only possible when decrypting the identity with the identity's current enScrypt settings and then re-encrypting it, determining the correct scrypt iteration count for the current device "on the fly" to accomodate for the password verification time set in the identity.

Otherwise, an identity created on a super powerful computer could take ages on a low-end smartphone to decrypt and vice-versa.

//EDIT:
This is a quote from https://www.grc.com/sqrl/SQRL_Cryptography.pdf, page 21:

I totally agree, but I don’t think Steve’s client reencrypts on import.

 

[Paul F]

I totally agree, but I don’t think Steve’s client reencrypts on import.

Here's some related information: https://sqrl.grc.com/threads/small-suggestions-re-identity-backup-export-output.1002/post-8405

 

[ramriot]

With Steve's app I can import an Identity without entering the password until it's needed. Having the same functionality here would make importing an identity quicker. It would also allow the identity to use the Rescue Code if the password was forgotten.

NOTE: One should NEVER sync identity to a new device with an exported file that is NOT one protected by a user provided password. Reason being that without that protection you will need to use the rescue code at least once on the new device before setting a user password & if the new device is already compromised then you have lost complete control of your SQRL identity & the re-key operation will not help you in recovering that security.

If SQRL identities are synced between devices in a form protected by the user password then a compromised device can only leak the current Master Key & and previous Identity Unlock Keys. An attacker knowing this would be able to impersonate you but would NOT be able to re-key, thus once you discover which device was compromised you can re-key on a known secure install, sync to other trusted devices with password protection & recover your identity.

 

[Brian Buchanan]

I'm unsure what you're referring to here, but I think you are mistaken.

You can "import" outside the app by copying the identity file into the correct folder. Inside the app, you need to have either the rescue code or the password.

Hi there,

I'll try to explain.

1. Start the app on my phone
2. Tap the folder in the top right
3. Tap the + sign in the top right
4. Tap Import identity from QR code
5. Aim the camera at the identity qr code
5a. Enter the name of the identity
6. Enter the identity password

With the grc client, I didn't have to enter the password to complete the import. I did of course have to type the password to use it later.

My thought was to complete the import process at 5, and not require the password (Or re-encrypt) until first use.

 

[Brian Buchanan]

NOTE: One should NEVER sync identity to a new device with an exported file that is NOT one protected by a user provided password. Reason being that without that protection you will need to use the rescue code at least once on the new device before setting a user password & if the new device is already compromised then you have lost complete control of your SQRL identity & the re-key operation will not help you in recovering that security.

Thanks, I didn't even think about copying the files, I just used the camera on my second laptop and noticed it didn't ask me for the password while the ios app did.

 

[PHolder]

1. Start the app on my phone

With the grc client, I didn't have to enter the password to complete the import

Unfortunately now I am even more confused. The GRC client is a Windows client. It doesn't run on a phone.

 

[Brian Buchanan]

Unfortunately now I am even more confused. The GRC client is a Windows client. It doesn't run on a phone.

I'm comparing my experience with the ios app against the windows app and contrasting the work flow differences around importing an identity (scanning qr code to be clear) in the two applications.

In the ios app it's not possible to import an Encrypted identity without providing the password, and making a typo in the password sends the user back to the beginning where they need to scan the qr code again.

Also, in the ios app, if the qr code identity is encrypted with a password, it's not possible to scan it using the recovery code.

Those problems do not exist in the windows app. I was able to import an existing identity completely without any password, and could open it with either the password or the recovery code.

It also seems I'm having a problem with terminology, is the process of adding an existing identity into a SQRL client not called "importing"?

Sorry for the confusion.

Edit: I started this thread in the online forums in the Jeff Arthur's IOS App forum. Is it possible my original message was distributed without that context? That would explain a lot.

 

[PHolder]

Okay, well I have never imported into the GRC client, and most especially not using a camera. TBH I didn't even know it could read a QR code. It sounds like the GRC client does not re-encypt the identity, and it REALLY should, IMHO. @Steve will have to explain his rationale for that. I was under the impression that the recovery code would be needed with an identity encoded without one, so it may be the case that the client you used to create the QR code that you imported into the GRC client is not giving you the option to choose which way to export it? Which client did you use to generate the identity that you imported into the GRC client?

 

[Brian Buchanan]

Okay, well I have never imported into the GRC client, and most especially not using a camera. TBH I didn't even know it could read a QR code. It sounds like the GRC client does not re-encypt the identity, and it REALLY should, IMHO. @Steve will have to explain his rationale for that. I was under the impression that the recovery code would be needed with an identity encoded without one, so it may be the case that the client you used to create the QR code that you imported into the GRC client is not giving you the option to choose which way to export it? Which client did you use to generate the identity that you imported into the GRC client?

I actually generated the identity with the GRC Client quite a while ago, but the machine got wiped and I was adding it back.

I had forgotten the password used to encrypt the identity and that’s when I discovered this difference in import workflow.

Since the grc client can import without a password and then open the password protected identity with either the password or the rescue code, I was able to use the rescue code to open, change the password and export again.

Jeff Arthur's iOS App Prompts for only a password when importing a protected identity and I couldn't use the recovery code. I found that Importing a non password protected identity does prompt for the recovery code when importing.

 

[Jeffa]

Hi,

Yup, I decided that during ID import I would always do a device specific re encrypt. This requires either a password, or a rescue code depending on what you are importing.

Jeff

 

[ahauser]

Jeff's client does everything right, imho.

 

[Paul F]

@Brian Buchanan has a point. The rescue code is intended to be written down and saved in a secure place. The password is intended to be remembered and not written down. One purpose of the rescue code is to recover from a forgotten password. A backup that can only be restored with a password is more at risk of being unusable than one that can be restored with a rescue code.

Given that a rescue-code-recoverable backup is a subset of a password-recoverable backup, the client could allow the user the option to import a password-recoverable backup either way.

 

[ahauser]

Given that a rescue-code-recoverable backup is a subset of a password-recoverable backup, the client could allow the user the option to import a password-recoverable backup either way.

I agree, this is something that could (and probably should) be added to the spec to allow for rare but unpleasant situations like the one described by @Brian Buchanan above.

Just for the sake of completeness, if someone wanted to do this today, he could download my IdTool utility, enable unauthenticated changes in the "Edit" menu, remove block 1 from his identity, save it back as a *.sqrc file and would then be able to re-import it using the rescue code in Jeffs client as well as in the Android client.

I have opened an issue for the Android client to suggest the addition of this feature:

Allow identity import using rescue code also for password-based exports · Issue #446 · kalaspuffar/secure-quick-reliable-login

Feature request. See the full discussion here, https://sqrl.grc.com/threads/adding-identity-without-password.1010/, where Paul Farrer made a good observation: The rescue code is intended to be writ...

github.com

 

[Paul F]

Just for the sake of completeness, if someone wanted to do this today, he could download my IdTool utility...

You should be able to do everything you want with the GRC client: Import the .sqrl file or QR code. Export it as "rescue only" .sqrc file or QR code; or reset the password and export it as "password+rescue code" .sqrl file or QR code.

 

[ahauser]

You should be able to do everything you want with the GRC client: ...

Right, Paul, good point!

Regarding adding this to the Android client, Daniel reminded me that this is implemented already. On the import screen where you're expected to put in the password, there is a "Forgot your password?" option down at the bottom that let's you reset the password using the rescue code.

@Jeffa, maybe you could offer something similar as well as soon as all the basic stuff is out of the way.

 

[ramriot]

I'm not sure but there seems to be some confusion here between the basic key structure spec & client UI oddities, this is what I understand & my rational for my above post:

TL>DR: Summary: protections on identity export & where/how you import need to be carefully defined & risky operations made difficult to find for users who are not explicitly aware of the risks. From the below, what do your export options actually mean & what is the UX restrictions present?

**In the below assume previous n Identity Unlock Keys (PIUKn) are assumed revokes & protected at rest by the user passphrase**

In the protocol key specification the root key is the Identity Unlock Key (IUK) which 256 bit, generated randomly & run through the Ed25519 make_private function to twittle a few bits to make it a private key, the associated public key Identity Lock Key is also generated. The IUK key when stored is encrypted using the Rescue_code as its passphrase, the ILK then is stored against the users provided passphrase & used during initial association to new sites to prime the ability to reKey later.

From the IUK the Master Key (MK) is generated using the EnHash function when stored it is encrypted against the user provided passphrase.

"Exporting an Identity" can be done a number of ways but not all of them are secure against expected threats. For example the following are possible (may be unsupported) export modes:-

1/ Export IUK alone unencrypted
2/ Export IUK encrypted against Rescue code
3/ Export IUK encrypted against Rescue code & MK / ILK unencrypted
4/ Export IUK encrypted against Rescue code & MK / ILK encrypted against user passphrase
5/ Export only MK / ILK unencrypted
6/ Export only MK / ILK encrypted against user passphrase

If we assume our initial device is secure & trusted (if it is not all bets are off anyway) then this is how I believe each mode should be utilised if available:-

1/ Should only ever be used as an offline export QR-Code printout or similar. This file should only ever be used for import to an offline trusted root device for identity recovery operations, leakage of this information constitutes an unrecoverable loss.
2/ Can be exported as QR-code or file & possibly stored online. This file should only ever be used for import to an offline trusted root device for identity recovery operations, leakage of information after decryption constitutes an unrecoverable loss.
3/ Should only ever be used as an offline export QR-Code printout or similar. This file should only ever be used for import to an offline trusted root device for identity recovery operations, leakage of the MK information constitutes an recoverable loss (via reKeying), leakage of the IUK see 1/
4/ Can be exported as QR-code or file & possibly stored online. This is the storage at rest condition for client devices, leakage of MK information after decryption constitutes an recoverable loss while leakage of the IUK is not revoverable, thus if the device is in any way suspect the rescue code should not be used.
5/ Should only ever be used as an offline export QR-Code printout or similar. I can be used to import identity to a trustworthy online device. Leakage of the information is a recoverable loss. I would not recommend this export if you cannot prevent 3rd party access to the hard copy. It cannot be used to reKey an identity because the IUK is not available.
6/ Can be exported as QR-code or file & possibly stored online. Leakage of MK information after decryption constitutes a recoverable loss. . It cannot be used to reKey an identity because the IUK is not available.

 

[ahauser]

@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?