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.
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.
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
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:
|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.)
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.
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.
Gibson Research Corporation is owned and operated by Steve Gibson. The contents
of this page are Copyright (c) 2014 Gibson Research Corporation. SpinRite, ShieldsUP,
NanoProbe, and any other indicated trademarks are registered trademarks of Gibson
|Last Edit: Oct 29, 2013 at 18:59 (168.85 days ago)||Viewed 34 times per day|