GRC's | SQRL Secure Quick Reliable Login Client Operation

SQRL User-Interface & Operation

Developers of SQRL clients are, of course, free to express their understanding of SQRL's operation with whatever user-interface design they choose. GRC's user-interface design, presented below, may be copied directly into other clients and for use on other platforms or used as a starting point. If possible, maintaining a common and similar flow and feature set would likely ease cross-platform use. Note, also, that since SQRL's user-interface strings will be freely available in at least 30 international languages and dialects, designing a close copy of GRC's UI will make immediate translations of the user-interface available.

The design of this page's array of user-interface dialogs consumed more than 60-days of time, because the act of thinking through every possible user-interface consequence of SQRL's initial technology resulted in many significant changes being fed back into the design, significantly improving its operation.

Now, after a total of six months of detailed design work following SQRL's announcement, we have a final stable design against which code can be written. That task is now underway for the creation of GRC's reference SQRL client.

Because the final casting of the design into running code is still likely to result in at least some small changes being fed back into the exact design of the user-interface, the dialogs below should be regarded as a user-interface design schema, rather than as SQRL's final design. We won't have a final design until it is expressed in code. For that reason, although SQRL will be written to support a multi-lingual interface, the translation of its user-interface will await the finalization of the first English-only edition. Once that exists the community at crowdin.net (see next section) will receive all of SQRL's final text strings to translate.

Multiple Language Internationalization

GRC's reference implementation of SQRL will be published in more than 30 major world-wide languages and their dialects. The translation is made possible through the “Crowdin” crowd-sourced translation facility and the participation of many wonderful and willing multi-language volunteers. GRC and the entire growing SQRL community thanks Crowdin for their kindness and generosity in making their service available to GRC, for this purpose, at no charge.

SQRL User Interface Flow

Overwhelming? The detailed presentation below may appear somewhat overwhelming for a typical SQRL user. But keep in mind that the purpose of this page is to display every avenue and option within the SQRL client. For the purpose of design and documentation, it lays out the entire SQRL client user-interface all at once. A SQRL user would typically encounter the initial identity creation dialogs followed by occasional password prompts. Everything else would be presented as the user's experience, needs and usage grows.

The user-interface flow chart to the left shows the entire UI-flow for GRC's SQRL client application.

In the typical case, the user would click on a SQRL link or scan a SQRL QR code. That action activates SQRL to respond to the “sqrl:” URL or QR code.
Depending upon the user's own configuration of SQRL for their use, they may (or very likely may not) be re-prompted for either their entire SQRL password or just its hint. The full SQRL password only needs to be provided once when SQRL is first used. Therefore, any re-prompting is only for the user's protection in environments where someone else might use their SQRL client without their knowledge. In environments where that's not possible, all password re-prompting, after the full password has once been provided, can be suppressed.
Assuming that all is well and normal, the only thing the user will ALWAYS see, is the single confirmation dialog (shown here to the left) that supplies the website's “friendly name” (not some confusing URL) to verify that this is the website the user intends to login to.
This single verification is important because without it a user could be intending to use SQRL to login to “BlackHats.com”, but the BlackHats.com site gives the user a SQRL code it just obtained from Amazon.com. Since Amazon.com would always identify itself as “Amazon” the user would be expecting to see “BlackHats” and not “Amazon”. (Note that SQRL's built-in man-in-the-middle (MITM) detection would catch this even before the wrong website's name was displayed, but not every possible SQRL operating configuration can benefit from SQRL's MITM detection and prevention, so SQRL always verifies with the user before login.)

Note, also, that this pre-login prompting dialog offers an “Other” options button which allows the user to perform non-login operations such as completely disabling the site's use of SQRL for security purposes or completely removing all trace of the user's SQRL identity from the site. These are uncommon, but available.

And that's all there is to it! The user will typically click a link on a site's login page, confirm that they're about to authenticate their identity to the site they expect, they click “YES” and they're logged in.

The detailed array of SQRL dialogs below lays out everything ELSE that the user might see during their management of their SQRL identity(s).

Home

When the SQRL executable (sqrl.exe) is run or its tray icon is clicked – and at least one identity has previously been created – this top level “home” dialog will be shown. From here the user can tweak settings, change their password, manage their SQRL identity(s) and browse the rather extensive built-in help.

If this is the first time SQRL is being executed on the computer, the “First Contact” series, shown below, will be started instead.

First Contact

The first time a user runs GRC's SQRL client on a new machine:

We want to be sure that newcomers understand how SQRL works and that they do not automatically create new identities for every instance of SQRL they use.

SQRL's “Personal Identities” are meant to be global, created once and reused everywhere.

Therefore, any time a SQRL client is run without a defined identity it should carefully educate and deter its user from creating additional identities.

The SQRL client assumes its user knows nothing about SQRL. It is designed to avoid annoying experts, while offering to help curious and willing new users acquire some understanding of what they need to do, and why. Since that first page (above) will only be presented the first time SQRL is run on a new device, it is the perfect place to offer additional information.

The “Learn more about SQRL” button presents this carefully designed, as brief but complete as possible, introduction to the few things every SQRL user should know. It is intended to be the quickest possible introduction to SQRL's main ideas.

Here is the complete, (currently) suggested reference text for each of those four tabs shown above:

In a Nutshell

Before you begin using SQRL to login to websites, your SQRL private identity must be created. You only need one, probably for life, because it reveals NOTHING about you, and it's highly secure. It's just a very long (77-digit) random number.

From then on, whenever you login with SQRL to a website, your private identity is used to generate another 77-digit number for that one website. Every website you visit sees you as a different number, yet every time you return to the same site, that site's unique number is regenerated.

This allows you to be uniquely and permanently identified, yet completely anonymous.

Since you never need to use an eMail address or a password, you never give a website your actual identity to protect. If the website's SQRL identities are ever stolen, not only would the stolen identities only be valid for that one website, but SQRL's cryptography prevents impersonation using stolen identities.

This is as good as it sounds. It's what we've been waiting for.

Your SQRL Password

SQRL frees you from the burden of logging into Internet websites by doing it for you. But this means if someone else gained control of your SQRL app, they could impersonate you.

We solve this problem with a SQRL password which YOU use to login to your SQRL. You decide how much login protection you need. You choose your own password of whatever length and complexity you desire. To impede someone guessing, you set how long any password takes to process. And to make longer, more complex passwords less painful to use, the password's first four characters may be used to "refresh" the full password you recently entered.

You are free to change your password and its various settings at any time. And if you should ever forget or lose your password for any reason, SQRL's Rescue Code can be used to recover your access.

SQRL's Rescue Code

You and SQRL will probably never need rescuing. But SQRL's security is so tight that you MIGHT need a way to unlock things a bit. Here are the two scenarios where you WOULD need rescuing:

• If you changed your password and the new one slipped your mind, there's no one to ask. Unlike websites, where you click "I forgot my password", your SQRL app doesn't know it either. If it did, it could be hacked and used to steal your identity. Backups you have made of your identity will have been saved under the password you were using then, so that might help. But your SQRL-assigned Rescue Code will always forgive any memory lapse.

• Once you have established your SQRL identity with a website, that identity can ONLY be changed with ITS Rescue Code. If someone WERE to somehow steal your SQRL identity (if your phone was stolen and you used a VERY weak or guessable password, or malware infected your device), they could never replace your identity with theirs. But YOU could retake your stolen identity by creating a new one and using the old identity's Rescue Code (which the bad guys would never have) to replace that old identity with your new one.

SQRL's Rescue Code is a powerful ally. Write it down, keep it safe and never lose it. You will probably never need it, but if you do you'll be very glad you kept it.

Why Backup?

Your SQRL private identity is a randomly chosen 77-digit number used to generate each of your individual web identities. NO ONE knows what it is. As you use SQRL to identify yourself to the Internet, your identity BECOMES that 77-digit number. If it is ever lost, so is your Internet identity.

The other reason to backup your private identity is to copy it into another computer or mobile device. Once your one private SQRL identity has been installed into all of your devices, you can use any of them to easily identify yourself on the Internet.

SQRL provides many simple ways to back up your private identity, and all backups are ALWAYS protected by your SQRL password and Rescue Code.

Printing backups onto paper, as a small QR code and text (perhaps more than once) is recommended, since paper is the original data storage medium. In many ways it's still the best. Simply store it where you store your life's other important documents. You can also record your backup to thumb drives, burn them to CD's, and store them safely anywhere.

But PLEASE do make backups, since NO ONE knows your unique 77-digit private identity... not even you!

Definition / Glossary Notes

In the text shown above, and as the UI continues below, terms have been carefully chosen in an attempt to clearly convey their purpose:

Private Identity: The UI text attempts to draw a distinction between the user's single private SQRL identity and the system's multiple per-website “web identities”.
Web Identity: The term “web identities” conveys the idea that SQRL users have unique identities at individual websites.
Rescue Code: The term “Rescue Code” was chosen to convey the idea that this somewhat daunting code will be needed only to “rescue” the user from extraordinary situations. As we'll see below, it's the high-entropy, high-security, system-supplied, 24-decimal-digit code that is used to key the encryption and decryption of what is essentially the user's root identity ‑ the Identity Unlock Key (IUK). (Please refer to the key-flow page for additional information.)

New Identity Creation

Here, we lead the user who believes they wish to create a new SQRL identity through the short list of reasons why they might actually want to create a new identity.

This both continues teaching them a bit more about SQRL, and further verifies that this is what they really intend.

As we lead the user through the process of creating a new identity, we need to explain about the “Rescue Code”, whose random 24-digit security is what allows the user's identity to be safely stored inside insecure PCs and devices.

The only impact this “Rescue Code” has upon the user is the need to just once record it permanently — either by hand or by printing. And since it can never be stored inside the generating PC or device, it must be recorded at the time a new identity is created.

This stage of the identity creation wizard explains this, and prepares the user for the need to be able to immediately and permanently record the new identity's “Rescue Code.” It gives them the opportunity to gracefully cancel this process before going any further if that won't be possible or convenient at this time.

To help users manage situations where multiple identities are installed into a single SQRL app, SQRL identities are named.

So here, the user is prompted to provide a name for a new identity they wish to create, or to select the name of an existing identity they wish to replace.

If the user chooses to replace an existing identity, the display of this explanation dialog will be triggered. The SQRL user interface presents help when it believes it will be needed. The main user interface panel can be used to display and disable SQRL's help dialogs once a user understands what's going on and attains proficiency, The help dialogs can also be redisplayed at any time.

The portion of the text that is “below the scroll” and not shown in the dialog to the left, continues . . .

[...] recognize the user by their identity which is being replaced.

When a user logs into a website that still recognizes them by their previous identity, SQRL will confirm that they wish to update that website's stored identity to their current identity, and, if so, SQRL will prompt the user for the previous identity's Rescue Code to permit its replacement. An identity's Rescue Code is always required to prove rightful ownership of any identity being replaced.

To help users replace their compromised identity at many websites, the long and secure Rescue Code only needs to be entered once per session.

As this dialog is displayed, a great quantity (you can never have too much, only too little) of unpredictable data is collected from throughout the host system to obtain a high-entropy (absolutely random) 256-bit SQRL identity. The user sees a simple progress meter as the “entropy pool” is filled past overflowing.

For the technically inclined: This entropy pool is created by initializing and opening a SHA256 hash function. Then, unpredictable data from throughout the system, including the system's processor, operating system, network, storage, audio and video peripherals is poured into and accumulated by the open SHA256 function. The “noisier” this is the better. Even “conversion uncertainty” in the audio and video digitizing analog-to-digital converters will be useful. This continues until many times the SHA256's maximum entropy has been amassed. Once this point is reached the SHA256 function is briefly closed to produce its first 256-bit hash result. This will form the new identity's unencrypted Identity Unlock Key (IUK). The hash function is then reopened, retaining its full state, and additional entropy is added. The SHA256 function is finally closed to produce another 256-bit value from which the identity's Rescue Code will be derived.

If the user wishes to understand a bit more about what's going on with this “entropy” collecting, they can click the “Additional Information” button to display the dialog to the left. The portion of the text that is “below the scroll” and not shown in the dialog to the left, continues . . .

[...] None of this is precisely knowable to anything other than SQRL when measured in fractions of billionths of seconds.

And in the interest of leaving no stone unturned, SQRL also absorbs the unpredictable "noise" being received though the system's audio and video devices when any are available.

SQRL absorbs ALL this, amassing a huge pool of chaotic, unrelated and unpredictable digital noise. It is then stirred together it such a way that every single binary bit of data collected is used in the final production of one unique SQRL digital identity.

Having created a new SQRL identity, the volatile Rescue Code which cannot (for security) be stored anywhere inside the computer must be written down, printed, or somehow recorded by the user. This stage of the identity creation wizard offers to either display the 24-digit Rescue Code (if it's safe to do so) or to print it to whatever printing facility the user's system may have.

Since we are really (really) not kidding about the necessity of recording the Rescue Code in some fashion that it can later be re-entered if needed, this next phase of the wizard prompts the user to re-enter the Rescue Code that they presumably have just written down. This serves to verify that, at least at the time of identity creation, they were able to correctly re-enter the Rescue Code. Since the Wizard's “Next” button is helpfully disabled until we have a Rescue COde match, one way or the other the user is going to re-enter the Rescue Code if they wish to proceed.

One of the reasons people use bad passwords is that no one ever really explained what they should do, and why. At this stage of SQRL identity creation we're about to ask the user to invent another new password. So we try to give this forthcoming request some context, and to briefly grab their attention about the fact that SQRL's SINGLE PASSWORD is fundamentally different from every other password they have ever used. It becomes the master password for their entire online identity. (At least to the extent that SQRL succeeds on the Internet.) We also “soften the blow” of asking them to invent a “long & strong” password by explaining that most of the time they'll be able to just use the “password hint” of the first few characters of the password.

This is SQRL's password design dialog. It allows users to see what they are entering if they choose (which is useful and sane when they have sufficient privacy). It also displays a continuously updated “Password Security” rating bar. Using this simple means they'll be able to experiment with any password construction solutions.

Next we do two things...

We need to verify that the user is able to re-enter their password in a typical password-entry mode. Once they have done that, we are finally able to encrypt and store this new identity in their SQRL client. Therefore, when the password verification field correctly matches their chosen password the “Set New Password” button (which was initially disabled and greyed-out) will be enabled. Pressing that button will initiate a five-second “EnScrypt” process shown by the progress bar. After that the “Next” button will be enabled, allowing the user to proceed.

Now that the user's new identity has been successfully created, they should export it from the PC into one of more locations and formats. So long as the Rescue Code is kept separate (see the next dialog panel) this is safe. So this panel explains that what has now been created can NEVER be re-created (it truly cannot). So we encourage them to back up their new identity right away. They can show it on screen as a QR code for acquisition by a camera-enabled device, save the file to a thumb drive for offline storage, or print it out onto paper (as with QR code and emergency-recovery ASCII code.

By default, SQRL identities contain both the encrypted Identity Unlock Key (IUK), which is the parent to the user's Identity Master Key (IMK), and the user's encrypted IMK.

Since the parent IUK is encrypted by the guaranteed maximum entropy system-supplied Rescue Code, it is safe against attack. But the saved IMK is encrypted under user's own password, over which we have no real control (even though we have strengthened it as much as is feasible).

Therefore, to mitigate the danger of a stored identity having a weak, password falling into hostile hands, we pop-up this dialog before any identity export to ask whether the user would like to have their password removed from the identity for storage. It's an additional step, but it should be clear and comforting, and it would hugely help to protect users who insist upon using weak passwords.

If the user asks to have their newly created identity displayed as a QR Code, after deciding whether or not to remove its password to eliminate the danger of a hacker obtaining it and exploiting a weak password, this dialog will be displayed until it is closed.

The user could then immediately scan the new identity into a mobile smartphone or tablet.

The SQRL application will always allow the identity to be displayed like this, but having the newly created and protected identity existing in multiple places constitutes a backup, so proactively offering it coaxes users not to procrastinate.

This final panel provides some useful and important tips for securely storing their identity. We remind them NOT to store the Rescue Code alongside the identity backup . . . unless they are both being stored in an honest-to-god safe that only they have access to. We also explain that all SQRL devicess should be kept “in sync”, so this new identity should be copied into any other devices, especially if this identity is a replacement for a previously existing identity.

Identity Import

If, in response to the very first dialog box above (“SQRL has not been loaded with an identity”) the user chose to import an existing identity rather than to create a new one, or if, at any time, they chose to import an existing identity, their interaction would proceed as follows. Since the function of most of this will, by now, be quite clear, comments are only added where there's something to add.

The printed format of an identity includes both a QR code for optical scanning and, as further backup for use with computers lacking cameras, a high legibility textual format presentation with ambiguous characters removed from the character set.

The textual format includes internal verification so that input errors can be caught.

During the design of SQRL one issue was whether exported identities should carry their name. If they did, it could be useful to confirm whose identity it was. But then when the identity is being imported you have the problem of a name collision. Do you rename the new one, the old one, replace the existing one? It seemed cleaner to treat the importation exactly like the creation of a new identity, where it would not carry a name, but could be given any name the user chooses or replace an existing already installed name — which is likely the most common choice.

SQRL Configuration Management

During a password change operation, we must re-encrypt the new password. This gives the user the opportunity to change their identity's password verification duration, if they choose. This panel saves them from making this change separately.

SQRL's Built-In Help Panels

Note: This section will wind up further down the page, but
I had this dialog written, so I wanted to get it posted.

This built-in help panel will be (optionally) displayed when the user requests additional information and help about SQRL's passwords.

The rest of the text, not shown below the scroll, is here:

[...] know it's really you until the processing is finished. The slower you make it, the more protection you have, and you can change the processing throttle at any time if it becomes tiresome.

• To minimize the annoyance of this deliberate throttling, a much shorter "hint" (only the first few characters of your password) can be used to easily reaffirm your identity any time you have previously given SQRL your full password. (SQRL keeps the full password, so it just needs to be sure you haven't wandered off and left your identity exposed.)

• At any time you wish, you may change your password or adjust the password processing throttle, or the number of hint characters, and how often, and when, you are asked to enter your hint or your full password. It's ALL up to you.

• These features are provided to offer a balance between your security and your need for convenience. If you always use this computer in a safe location, you might safely eliminate the prompts for password hints altogether, while keeping them active if you use SQRL on a mobile device.

• If you needed, for some reason, to divulge your identity's password to someone -- perhaps a family member in an emergency -- you'll be able to change your password later to retake control of your identity. But suppose THEY used your password to CHANGE your password? This is one of the powers of the "Rescue Code": It allows you to recover from a lost, forgotten (or maliciously changed) password.

User Passwords

Since SQRL authenticates to websites on its user's behalf, SQRL's password system is used to authenticate the user to the SQRL client. This is done to prevent unauthorized use of the SQRL client to log into websites or perform any sensitive SQRL operations (such as displaying the user's private SQRL identity for export. (Actually, SQRL's security management is such that the SQRL client doesn't even have the user's private SQRL identity for export unless the user enters the key.)

The dialog prominently displays the user's identity name. Although typical SQRL clients will only be loaded with a single user's identity, multiple identities per SQRL client will be supported and can be used when needed. For example, family members might wish to cross-load their IDs into each other's devices for convenience. Or a shared family PC might be loaded with the entire family's identities. The need for continual password re-authentication makes that safe.
When a SQRL app is loaded with more than one identity, the “Select Identity” link will appear, allowing its user to change the currently selected identity shown in the password dialog's title. And an option in the application's settings will also instruct SQRL to always ask which identity should be used before displaying the password dialog.
Since user passwords deliberately require several seconds of process, the password entry field doubles as a progress bar once the user hits “Enter” or clicks “OK”. This helps to pass the time while the entered password is being processed so that the user knows that something (useful) is going on. As mentioned above, the user can set this processing time themselves, with the understanding that shorter time means that guessing is easier (both for non-malicious friends and definitely malicious bad guys). They should also keep in mind that their full password only needs to be entered after a long period of inactivity or whenever SQRL is first used. . .

To encourage users to adopt a strong, attack-resistant (and time-consuming to enter) SQRL password, we “soften the blow” by allowing just the first four characters of the user's password to be re-entered during the same session when SQRL has already been initially provided with the user's full password. We call this a password “hint”.

By default, events which terminate the current session, such as locking the device, logging out of the operating system, or engaging a screen saver, will cause SQRL to immediately overwrite and erase its RAM-resident user password, thus ending the user's session.
When the user's session is still active, but SQRL needs to re-verify that the user is still in control of the device (which it will do frequently to assure the user's security), it will prompt for a “hint” of the user's full password ‑ only the first four characters.
SQRL adopts a zero-tolerance policy for hint mistakes: If the four characters entered do not perfectly match the first four characters of the user's password, the session will be immediately terminated with the in-RAM password overwritten and erased . . . after which the user will be re-prompted for their full password.
In normal use, this allows the user to quickly and effortlessly re-assert their identity to SQRL, while anyone else attempting to use SQRL immediately afterwards would almost certainly lock themselves out, and also give away the fact that an erroneous password hint had been attempted.

Access to Other Operations

The “Other” button on the “confirm that you wish to login” dialog leads to this dialog which offers the user options other than logging in. Specifically, temporarily disabling SQRL's access to a specific website's login or permanently removing all trace of SQRL from the website.

SQRL Status Exceptions

The red-colored decision diamond in the user-interface flow chart at the top of this page with the caption “Status exception of some kind” diverts the normal uneventful SQRL login process down another path. Depending upon the status returned by the remote web server, one or two of the following dialogs will be presented for user action.

One of SQRL's under-appreciated features is its ability to offer some protection from man-in-the-middle identity impersonation attacks. For clients (such as Windows, Mac, or Linux) co-existing in the same machine as the website, where the client's SQRL querying IP address would be expected to be the same as the web browser's, this simple “the IP's are not the same” warning can provide significant protection.

The rest of the text, not shown below the scroll, is here:

[...] For example, if you clicked on a link you received in electronic mail or somewhere else, rather than entering the website's URL name manually into your web browser, that link you clicked on might be fraudulent and may have taken you to a copy of the Amazon site designed to convince you that you were really at Amazon.

If you are in any way unsure about the source of this SQRL login link, your recommended course of action is to ABORT this login by pressing the ABORT button below, then manually enter the URL of the website you wish to access. If the problem persists this is likely a "false positive warning" that you can safely ignore.

If you are using a network that always produces this warning, you may permanently suppress it by disabling the "warn of possible man-in-the-middle" attacks on the settings and options page.

Please choose how you would like to proceed:

		Secure Quick Reliable Login
		A highly secure, comprehensive, easy-to-use replacement for usernames, passwords, reminders, one-time-code authenticators . . . and everything else.