NOW SpinRite 6.1 – Fast and useful for spinning and solid state mass storage!
100x100 SQRL Logo   Secure Quick Reliable Login
A highly secure, comprehensive, easy-to-use replacement
for usernames, passwords, reminders, one-time-code
authenticators . . . and everything else.
The SQRL system (pronounced “squirrel”) revolutionizes
web site login and authentication. It eliminates many
problems inherent in traditional login techniques.
A bold statement indeed
Given the rich history of the Internet, and the number of very smart people who have worked to develop its technologies, that red headline above deserves to raise eyebrows. Nevertheless, this page, coupled with the previous introduction page and the next crypto technology page, aims to demonstrate and fulfill that headline's claim — in full.

The user's view of SQRL features & operation

The previous SQRL introduction page provided a sense for the SQRL system's ease-of-use, and the operation of its cryptography. This page describes the rationale for the operational features the user sees without regard to the underlying enabling technology. The Crypto architecture page follows this page with a detailed description of the cryptography that delivers this feature set.

Choosing to NOT outsource identity authentication

As discussed on the introduction page, in an era of government-sanctioned preemptive data collection and eavesdropping, the exclusion of all third-party involvement is the only means for 21st century citizens to guarantee their autonomy and privacy. But that means that all of that responsibility rests with them. If not with them, then with whom? This responsibility has two aspects: In other words, only the smartphone's owner can use the system to assert their identity, and nothing will prevent them from asserting their identity whenever they wish to. We will address each of these requirements in turn:
ONE attack-resistant master password

Wait!  . . . We're back to passwords???   Not plural.   Just one password.   But, yes.   The SQRL system was specifically designed to eliminate username and password authentication to remote websites. But controlling access to SQRL authentication itself requires the smartphone's owner to prove their identity to their own phone.

And to that end, “a secret only the user knows” is still the best technique for users to repeatedly, quickly, easily and privately prove their identity to their own smartphone.

The cryptographic design of the SQRL system inherently provides identification security for every website it contacts. In that sense the system itself is fully secure without any password protection. We refer to the SQRL password as a “local password” because it is only used to prevent others from using the SQRL smartphone app to impersonate its owner.

One local authentication password is therefore needed, only because current smartphones do not provide sufficient security over access to their applications. Even Apple's TouchID fingerprint recognition can be spoofed (though only with considerable effort). But authorities can compel a phone's owner to place their finger on the phone's unlock button. In comparison, many jurisdictions provide individuals with explicit protections against self-incriminating testimony; this encompasses anything the user knows, and specifically includes memorized password secrets.

If smartphone application access security should strengthen in the future, or if a user is in a situation where their smartphone is never subject to any possible misuse, and so long as the user understands the responsibility, then their “local unlock” password could be left blank without reducing the network security of the SQRL system at all.

A workable password compromise

The trouble people have with passwords is that they have learned that, for true security, they must not use the same password to authenticate themselves at multiple websites, and that each of the endless number of separate passwords must be long, complex, and effectively impossible to remember.

The other human-factor aspect of passwords is that a password used frequently tends to be remembered. Conversely, passwords which are “difficult to remember on a good day” tend to be quickly forgotten when not continuously reinforced through use. By requiring the use of just one strong password (yes, passcode, passphrase, whatever), which can be of any length and complexity and composed of any characters, the user's memory and facility with that password is continually refreshed.

The SQRL system avoids these traditional password problems by requiring just one strong master password of the user's choosing. This authenticates the user to their smartphone, thus protecting the use of the owner's SQRL identity authentication from blogs to banks. Since this single password is only used internally for local decryption, and never leaves the smartphone, it is never in danger of being captured remotely.

The crypto and attacks pages explain the details of password operation and authentication, but suffice to say that the user's identity-protecting password can be freely changed at any time by entering the current password to unlock the identity settings, then entering and confirming a new password. If, when setting a new password, a mistake was somehow made twice, so that the user managed to enter and confirm a password change that they are then later unable to reenter, a straightforward password recovery solution exists and is explained below.

A password lockout system prevents a casual attacker from endlessly guessing passwords. After a user-configurable number of password failures, all SQRL usage will be prevented until password recovery is performed.

Any use of the SQRL application requires password authentication of the user. This includes changing application settings, adding and removing user identities, importing or exporting backup identity keys, and performing website identity authentication.

This requirement for the use of just one strong local password solves the first of the two problems posed above: Preventing unauthorized assertion of identity. Now let's look at the second problem.

Preventing loss of authorized assertion of identity

Backing up, cloning and transporting SQRL identities

The importance of this should be obvious. With virtually all of one's identity concentrated into a single facility, prudence demands that the identity information be protected from loss. And convenience suggests that the identity information should be transportable among smartphones and to any other similar devices in the future.

As we will see on the crypto page, a user's master key consists of 512 random bits of binary data. The QR code below represents exactly 512 bits of random data. Odd as it may be to contemplate, in an SQRL world, THIS unique pattern of black and white could securely represent a person's entire online identity for the duration of their life:

Smartphone SQRL apps import, export and transport their owner's 512-bit
master keys in the form of universally understood QR codes.

SQRL master keys are always encrypted under the user's current password. The
crypto architecture requires that the master key, whether inside or outside of
the smartphone, has been encrypted with the user's password. All SQRL master
keys exist “statically” in encrypted form. This specifically allows the master key
to be securely exported and safely transmitted over insecure channels, such as
eMail. Without its matching password, anyone's password-protected master key
is a useless collection of 512 bits, as valid as any other and of no value to
anyone.  (The crypto and attacks pages examine and confirm this assertion.)

To backup the crucial, potentially life-long, master key:
Once a user has started using and relying upon the convenience and security of the SQRL system, they will certainly wish to protect their identity from loss by creating, printing, and securely storing one or more offline printed paper copies. Remember that since SQRL master keys are encrypted under the current password, A MASTER KEY SHOULD NEVER BE EXPORTED UNLESS IT IS PROTECTED BY A STRONG PASSWORD. SQRL apps should always warn their users if a null password is in use at the time of master key display or export. If, for example, no password was encrypting an exported master key and an adversary was able to scan it in that state, the user identity represented by that key would be completely compromised.

This somewhat frightening (but ultimately unavoidable) exported key responsibility is offset by the fact that SQRL apps strongly protect the encrypted contents of their owner's exported identity master key: The computation to export an identity master key is designed to deliberately require 60 full seconds of intense processing of “memory-hard” functions by the device performing the export. The crypto page explains the details, but the point is that once it has been exported in this fashion, every attempt to import the identity master key must duplicate that same, extremely acceleration-resistant, processing. Legitimate master key export and import are infrequent and rare operations. And the user's correct password would be used. So waiting just 60 seconds—in return for extreme over-the-top security—is not burdensome. But this makes guessing the password, impossibly slow. The state-of-the-art encryption technology has been specifically designed to defeat GPU and FPGA acceleration, and it cannot be bypassed. So even though prudent users should and will keep their exported identity master keys private, as long as a good password is used, modern cryptography knows of no way for it to be brute-force attacked and cracked.

Therefore, assuming that a master key is protected by a strong password, it would be safe to eMail it to oneself for printing and/or safe keeping. It would probably be wise, however, to add some sort of strong clue about the password that was in use at the time of the key's export because that password will be needed if the QR code is ever required to reestablish a lost identity.

Remember, we deliberately want the security of there being no one else to go to in the event of loss, but that means . . . there's no one to go to in the event of loss. Even so, it would not be the end of the world. But you would need to create a new and unknown identity, then re-associate it with your important online accounts. It would be much better just to take the time to export secure backup copies and store them safely.

If a truly secure environment existed for printing and safe keeping—such as a personal safe deposit box—the user's password could be briefly removed, the password-free master key exported and printed (and clearly labelled as “dangerous and must-be-protected”), then a password restored to the identity. That would allow the QR code to represent the identity of its user without any password . . . with clear security consequences. It is never our intention to restrict freedom, only to offer tools to provide security.

To clone the identity stored in one phone into another:
The source phone's user password must first be used to unlock the SQRL application services. The unlocked smartphone would be instructed to display the users' 512-bit master key on its screen (as always, this is in encrypted form), and a 60-second timer in the user-interface would count down as the key was being prepared for export. Once it is ready, the target smartphone would be instructed to define a new user identity using an external QR code scan to provide the master key. To complete the transfer and “activate” the new identity in the target smartphone, the matching password must then be correctly entered and a second processing interval (determined by the processing power of the receiving device) would occur while the decryption was removed from the freshly imported key.

To remove a password security lockout:
For a local SQRL password lockout to occur on a user's smartphone, someone—presumably not the user—would have to fail several times to properly enter the correct password to unlock their identity. This might mean, for example, five failures, configurable by the user, and might also incorporate a “wrong guess” response delay during which the user-interface would be non-responsive. Since impersonation is considered a serious breach of security, once the count of successively incorrect passwords entered has hit its limit, the SQRL application will erase the user's master key by overwriting its entire 512-bits with all 1's. This special case can only occur in response to local password guessing. Subsequently, whenever the SQRL application sees that is has a master key of all 1's, the user interface will display a notice that the master key has been erased to protect the owner's identity due to excessive password guessing. Since this is a large inconvenience to the phone's owner, the mischievous guessing party will be notified when two, and one, guesses remain before the user's secure identity is erased from the device. The hope is that someone who is merely playing around (for example an innocent child) will cease guessing not wishing to cause the phone's owner undue trouble.

At the point of password lockout and secure deletion, the only recourse will be to allow the smartphone to re-scan a copy of the identity QR code and reenter the identity password. Since exported SQRL master key QR codes are securely encrypted, it would be safe to keep a copy in a wallet or purse if it seems likely that others might be tripping the security lockout frequently and/or being locked out until the identity could be reloaded would be a problem.

To recover a forgotten password:
Password recovery is essentially identical to recovering from password security lockout. It is always possible to fall back to the exported and printed master key and password. The smartphone's SQRL application will allow any user who knows the password to securely delete their identity from the application. And even if the identity password is unknown, an existing identity can be overwritten by importing a backup master key. So it will always be possible to refresh the user's identity to bring it out of any state of confusion.

Next . . .
The “crypto” page details the algorithms and cryptography required to turn these concepts into a practical working system.

Secure QR Login (SQRL) Documentation:

Jump to top of page
Gibson Research Corporation is owned and operated by Steve Gibson.  The contents
of this page are Copyright (c) 2024 Gibson Research Corporation. SpinRite, ShieldsUP,
NanoProbe, and any other indicated trademarks are registered trademarks of Gibson
Research Corporation, Laguna Hills, CA, USA. GRC's web and customer privacy policy.
Jump to top of page

Last Edit: Aug 02, 2015 at 14:17 (3,247.02 days ago)Viewed 3 times per day