SQRL User Q&A

SQRL identities are always protected by extremely strong encryption. Each time your identity is used, it must be briefly, just for an instant, decrypted. Your identity password is required for that. But once your identity has been decrypted, for subsequent quick access it is temporarily re-encrypted using only the first few characters of your password. You decide how many. It could be just one, but a few more would be safer. Then, since SQRL knows how many characters were used, you only need to type those first characters to immediately re-unlock your identity. So “Quick Unlock” is a convenience feature to reduce the frustration of frequent re-use of SQRL. There’s no reason to force you to re-enter your entire password every few minutes. When your screen blanker engages, your workstation is locked, or your session is suspended, or you logout or shutdown, your temporary decrypted password will be forgotten for your protection.

As explained by the previous answer, your identity is encrypted with your password. But your identity is also even more strongly encrypted with your identity’s Rescue Code. Your password is used for your normal use of your identity. You are not expected to remember your identity’s Rescue Code, but you must not lose it. Your rescue code has a number of special powers:

1. If you have ever forgotten your password for a website (and who hasn’t?) you needed to ask the website to send you a recovery email. But SQRL is super-secure because no one but you knows your SQRL password. So if, for example, you were to change it then forget what you changed it to, there’s no one for you to ask for help. Only your identity’s “Rescue Code” can rescue you from this situation and several others…
   
   
2. If you ever believe that your SQRL identity may have been compromised – like by malware, a hacker or a government agency – your Rescue Code gives you the unique power to “rekey” your identity. Since your identity’s Rescue Code is stored “offline” on paper somewhere, no one who might steal your identity from any of your devices will have it. This means that only you can “rekey” your identity. After you rekey your identity, every website you visit will initially recognize you by your original identity’s key, then will immediately discard it and replace that old key with your new one. After that, no one who might have your previous identity will be recognized by any sites you have visited with your rekeyed identity.
   
   
3. If circumstances prevent you from immediately rekeying your identity and visiting important websites to update them, you can use your regular SQRL identity to disable SQRL access to prevent the use of your stolen identity at any sites you visit. Once you have disabled SQRL access, no one with your identity (not even you) can use it to sign in as you. For that you need your “Rescue Code”. You could re-enable access, but you would probably choose to also rekey your identity for additional protection at the same time. SQRL makes all of this easy to do.

Your Rescue Code is so secure that it’s only known briefly when your identity is created and it MUST be written down or printed on paper and stored somewhere safe. If all goes well you will never need it for anything. But if you ever do need it, you’ll be glad you have it!

In brief: Your identity and your identity’s Rescue Code. That’s all.

You can backup (export) your identity any time by printing it on paper or storing it in a file. Your identity is encrypted, so storing it on a thumb drive is safe. But nothing beats a hardcopy printout for offline security. So we recommend exporting your identity to paper. Since you will likely have your SQRL identity loaded into several devices – your computers and smart phones – losing your identity is unlikely since your other devices serve as backups. But as mentioned in the previous answer, your Rescue Code is different and special. It is so secure that it is only briefly available at the moment your identity is created. It is never stored on any computer and it should never be. You must write it down or print it out and store it safely offline.

If you do these few things you can safely use SQRL, without worry, forever.

An exported SQRL identity can always be decrypted with its Rescue Code. But for ease of use it can also be exported with its password. This allows the identity to be imported into other devices and used without its Rescue Code. However, since the identity can be decrypted with its password, it is less safe to store archived copies of your identity with its password. Therefore, if you are exporting your identity for immediate use, exporting it with its password will be more convenient. But if you are exporting your identity for long-term backup storage, exporting it without its password will make its encryption far more difficult to crack if some villain should somehow obtain it.

Almost never. The Internet has given us a multiple username habit which can be difficult to break. Since websites see SQRL users only as a string of text like “E6Qs2gX7W-Pwi9Y3Kam-kuYjLSWXCt-yBcymWl-HAuo”, all SQRL users are anonymous. There’s no way to be “more” anonymous. If your reason for wanting another SQRL identity is to have another identity at the same website, SQRL already provides “Alt-IDs” (see the next question) for that.

The one place where you might need to create a second identity is when you wish to share a SQRL sign in at a website with another person. Say, for example, Mom and Dad need to share their ability to sign into their online banking with SQRL. The SQRL system already provides for this with SQRL’s “managed shared access” which provides shared access to websites with separate SQRL identities. But it’s possible that in SQRL’s early days not all websites will support SQRL’s managed shared access. So in order to share access to some websites, it might be necessary to also share a separate SQRL identity. Once SQRL’s managed shared access becomes available the shared identity can and should be retired.

There may be a time when you wish to sign into a website as someone the site has never seen before – an alter ego. Back in the old days of usernames and passwords, you would invent a new username for yourself to create another account, and thereby pretend to be someone else. SQRL’s alternate identity (Alt-ID) provides this capability. Any time you wish, you may use an alternate identity when you sign in to appear as a new and different SQRL user. Alternate identities are just some text you enter – any text. You can have any number of alternate identities, and if you reuse the same text when you sign in again, you will again be seen as that same “other” person.

The SQRL system is not only far more convenient than traditional usernames and passwords, it is also far more secure. But if both SQRL and usernames and passwords are available, attackers will still be able to get around SQRL by using an account’s username and password to sign in. “Request only SQRL sign in” is the solution to that. Once you have become comfortable with SQRL and have your identity and Rescue Code safely printed and stored offline for safe keeping, you can enable SQRL’s request that all non-SQRL sign in be disabled wherever you go. The next time you sign in with that option enabled the website should see and remember that request. This is only a “request” because SQRL cannot force websites to disable all other non-SQRL sign in. But SQRL users can easily test to see whether a website is honoring their request by trying to use their previous traditional sign in. If they are still functioning SQRL users can ask for SQRL-only sign in requests to be honored.

This is related to the previous option. If any form of “account recovery” is allowed, then an attacker who obtained access to your email account could use the “I forgot my password” option to obtain a link to reset the account’s password. It happens every day. So once you have become comfortable with SQRL’s operation and have your SQRL identity and Rescue Code safely printed out and stored away, you can enable this option to request websites to disable both their automated and their human-assisted account recovery. You should have the right to take this responsibility if you want it.

You must not lose your Rescue Code. It can never be recovered or recreated. You could use SQRL for a lifetime without ever needing your Rescue Code even once if you never forget your identity’s password and if you never need to rekey your SQRL identity. But if you are making a commitment to SQRL you really should have your identity’s Rescue Code.

But let’s say that you created a SQRL identity in the early days, didn’t take it seriously enough, and lost or misplaced your identity’s Rescue Code. For one thing, if you don’t know where your printed Rescue Code has gone, it may not be safe to continue using a SQRL identity when someone might have found its Rescue Code. So…

1. First, create a new replacement SQRL identity which you will now take seriously. Print out its identity and Rescue Code and store them in a known safe place.

If SQRL sites are supporting SQRL’s managed shared access (msa) facility you can handle the replacement of your old and no longer fully useful SQRL identity yourself:

1. Sign in with the old identity you are retiring.
2. Go to the site’s SQRL managed shared access page and issue an invitation with “management” rights.
3. Sign out of the site with the retiring identity.
4. Sign in with your new replacement identity and use the invitation to join your account.
5. Use your management rights to delete the old retiring identity. You will be granted ownership of the account at that site.

You will need to do this for all sites where you use SQRL which support managed shared access. It’s not automatic, but it’s guaranteed to work. For sites not offering managed shared access you will need another solution.

You will need to:

1. Sign in to the sites where you need to retire your original identity with the “Request only SQRL sign in” and “Request no account recovery” options turned off so that your security is reduced and all possible forms of account recovery will be available.
   
   
2. Contact the site’s administration and use whatever means they may have for replacing a lost or no longer trusted SQRL identity. It is against SQRL policy for sites to change SQRL identities for this reason since SQRL builds this in with its Rescue Code. But, at least in the early days, we expect that if SQRL users can arrange to somehow convince a site that they are the authentic site user – perhaps by falling back upon their original username and password and email recovery – then it seems reasonable that a site might be talked into helping.

The best way to become more familiar and comfortable with SQRL is to use it. This forum supports SQRL and GRC has a SQRL demo page at: https://sqrl.grc.com/demo and if you wish to experiment with SQRL’s more advanced “managed shared access” features you can find them at: https://sqrl.grc.com/msa. And… these forums are filled with people who use SQRL, many of whom have been working with and contributing to its development for many years. So please feel free to ask questions. You’ll find the answers here.