I just came across https://www.grc.com/sqrl/sqrl.htm
With Secure QR Login, your phone snaps the QR code displayed on a website's login page . . . . and YOU are securely logged in.
This seems like it would be pretty awesome - one of the problems that I can think of is if the QR reader is compromised, to display www.google.com instead of www.nsa-super-secret-place.gov/123. What other problems does this system have?
As usual, take anything related to Steve Gibson with a truckload of salt. Obligatory attrition.org link.
Let's have a look at Gibson's description of his protocol.
The QR code presented near the login prompt contains the URL of the authentication service for the site. The URL includes a securely generated long random number so that every presentation of the login page displays a different QR code. (In crypto circles this long random number is known as a “nonce.”)
The smartphone's SQRL authentication app cryptographically hashes the domain name of the site keyed by the user's master key to produce a site-specific public key pair.
The app cryptographically signs the entire URL contained in the QR code using the site-specific private key. Since the URL includes a secure long random number (the nonce), the signature is unique for that site and QR code.
The app issues a secure HTTPS POST query to the QR code's URL, which is the authentication service for the site. The POST provides the site-specific public key and the matching cryptographic signature of the QR code's URL.
The authenticating web site receives and acknowledges the POST query by returning a standard HTTP “200 OK” with no other content. The SQRL app acknowledges the successful submission of the user-signed QR code.
The authenticating site has the URL containing the nonce which came back from the login page via the user's smartphone. It also has a cryptographic signature of that URL, and the user's site-specific public key. It uses the public key to verify that the signature is valid for the URL. This confirms that the user who produced the signature used the private key corresponding to the public key. After verifying the signature, the authenticating site recognizes the now-authenticated user by their site-specific public key.
The biggest thing that jumps out at me is the use of a "master key" by the user. If I am reading the protocol correctly, that single master key controls the user's entire online identity...
Presumably, this master key is stored in the user's phone in an application database. Which opens up a huge gaping attack vector in the form of malware designed specifically to steal the master key.
So let's compare the difference between what happens when a password gets compromised vs what happens when the master key gets compromised. Assuming that you are following good password practices of long, unique and highly random passwords stored in a password manager, all you have to do is change a single password if it gets compromised. What happens if your master key gets compromised? You will have to somehow get all the sites you authenticated with to recognize that your master key has been compromised. The only problem is, since you do not have any other means to authenticate with the site such as usernames or email addresses, how will the site know that it is in fact you that is trying to revoke the master key?
Like anything that comes out of Gibson, this SRQL scheme is highly flawed and offers no benefits over conventional methods.
Overall, the protocol does not appear to increase security over existing technology. If you are looking for the best way to protect your identity online, this is without question not it. But let's go over the pros and cons:
It's impossible to "share" a password in the narrow sense that a malicious website can't use the authentication provided to one site to log in to another site.
A brute-force attack against the authentication token is not feasible.
Credentials are not stored on your computer. This protects you against a small subset of workstation-directed attacks. Specifically, you're protected against attacks that steal your password from your computer. You are not protected against any sort of session hijacking or browser-takeover attacks, though, and you are now also susceptible to phone-related attacks. More on that later.
This technique is dangerously susceptible to MITM attacks and social engineering. Probably more so than any other authentication scheme in use, including passwords. The authentication step and the login initiation step are inherently disconnected in the sense that the phone will correctly authenticate against any presented QR code, no matter how or where it gets presented to the user.
So, for example, a phishing site can display an authentic login QR code which logs in the attacker instead of the user. Gibson is confident that users will see the name of the bank or store or site on the phone app during authentication and will therefore exercise sufficient vigilance to thwart attacks. History suggests this unlikely, and the more reasonable expectation is that seeing the correct name on the app will falsely reassure the user into thinking that the site is legitimate because it was able to trigger the familiar login request on the phone. The caution already beaten in to the heads of users regarding password security does not necessarily translate to new authentication techniques like this one, which is what makes this app likely inherently less resistant to social engineering.
This technique combines both authentication and identity into a physical object which is frequently lost or stolen. In this sense it's more like a passport rather than a password. Anyone in possession of your phone is suddenly exclusively in possession of your identity: not only can the attacker impersonate you, but without a second copy on a second phone (unlikely), now you have lost the ability to identify yourself. Authentication keys are not revokable, so without out-of-band recovery from each and every site, you cannot recover your identity. And even if out-of-band recovery exists, when confronted with two users, one with possession of the identity and one without, it may be difficult to see why the site operator should trust you.
This technique combines all your authentication tokens into a single key unless you manually create others. This makes your one key an extra-juicy target for attackers. Furthermore, the key is stored on your phone, which devices have typically had laughably porous internal security. Combining unusually juicy targets with substandard security does not make you safe.
The most problematic aspect of this scheme is how poorly it compares to the available alternatives.
The most secure universally-accepted option today is lastpass, keepass, and other such browser-integrated password systems. In particular, client-side encryption alleviates the need to trust any third party. And more importantly, browser integration makes phishing practically impossible. LastPass or KeePass will only fill the password if served from the correct domain, which means that if presented with a malicious site, the user won't have access to his password.
Furthermore, LastPass recently added a feature which nags users to change passwords that are not globally unique. This helps prevent password re-use, which means the primary benefit of Gibson's technique can easily be gained using this tool today on existing sites, without the added insecurity his scheme implies.
Existing second-factor authentication schemes which use phones or similar devices help protect user logins today already do so in such a way that doesn't make you immediately vulnerable to identity theft if your device is stolen. The added security of two-factor authentication lies in the fact that neither the device nor the password can be used if stolen without the other. Gibson's technique is largely resistant to being included in a two-factor scheme, which makes this level of protection unavailable.
Gibson's authentication technique does not create sufficient benefit to overcome the additional security costs that it also imposes. These costs are a fundamental part of the scheme itself and cannot likely be worked out without scrapping the whole design.
You could argue that it's better than nothing, but you can't argue that it's better than anything we already have.
Gibson recently announced some additional protection against phishing because this has been a major criticism. Their protection is this: If you're NOT using the QR codes, cell phone, etc., and instead have an authentication agent on your system (in-browser, for example), then the server can check to make sure that the authentication response comes from the same IP as the authentication request. This is good and well, but the whole purpose of this protocol is move your identity to your cell phone. If the only safe way to use the protocol is to not use it's core feature, then perhaps we should re-think what we're trying to accomplish.
Theoretically you could continue to use your cell phone if (and only if) your cell phone knew that it was using the same IP as your computer. Which, of course, it can't know because it doesn't know your computer's IP address.
As stated before, if the authentication measure is in your browser, then the whole phishing problem is immediately solved with no effort or verification on the part of the user. Even the least capable user can't be tricked into authenticating to the wrong site because the site's authentication token is associated with the domain name, and the browser won't allow authentication to the wrong domain. This is a technique already in use today, is completely automatic, and does not require the site's cooperation or any intelligence on the part of the user.
This method can be strengthened by requiring a second authentication factor (such as a time-varying key on a cell phone) which, again, is already available and in use today, which protects you (most notably) against screw-ups on the part of the destination site or company.
As for concerns about browser-side authentication being vulnerable to client-workstation attacks: while the is true, it's also true that if your browser is compromised, then no usage of that browser is safe, no matter what authentication mechanism you use. Malware authors can (and already do) wait for you to authenticate on your own using your super-secure technique, and then silently send the necessary traffic to "own" your account, all without you seeing anything amiss. Neither SQRL nor any other authentication system can protect the user of a compromised browser, any more than door locks can protect you from a house fire. Buying fireproof locks is not a solution.
If you're looking for an absolute guarantee of protection from impersonation, then look at the Fido U2F token. This standard shines where SQRL falls short, and gives you guaranteed immunity to MITM (e.g. phishing) attacks. It does so by authenticating not just the user, but also the channel, so you're guaranteed that (a) your account can't be authenticated without the token, and also (b) your token can only be used to authenticate a connection to the machine it's attached to. See this answer for more information.
SQRL certainly is not without flaws, but it's certainly superior to most primary authentication solutions widely used on the web today in terms of security and (and this is important) usability. Allow me to explain.
First, let me clear up a few of the misconceptions present in some of the other answers on this question. Many of these answers are outdated, and were written before changes to the SQRL documentation which address the problems presented in them, while others seem to place undue emphasis on flaws in SQRL which are also present in many other widely-used existing authentication solutions, while ignoring its benefits. So let's clear up a few misconceptions here, shall we?
This simply isn't true. QR codes are a convenience which makes SQRL easier to use on computers that the user hasn't set up SQRL client software on. SQRL's website states the following:
Three Ways to Go . . . smartphone optional:
Although the original inspiration for the development of this system was a smartphone scanning a QR code on a website's login page, a small addition to that model enables two more significant modes of operation: Simply make the QR code image also a clickable link to the same URL that's encoded into the QR code. This yields three ways to login:
- Scan the code with a smartphone: Using the model described above, a user's smartphone scans the QR code appearing on a website's login page and the user is logged into that site.
- TAP THE CODE on a smartphone: To login to a website ON the smartphone, when the visual SQRL code is also a URL-style link (using sqrl:// as the scheme) the SQRL app installed in the smartphone will receive that link and securely log the user into the site on the phone.
- Click the code on a desktop or laptop screen: To use the SQRL system on any desktop or laptop system, a desktop SQRL application would be installed and would register itself to receive sqrl:// links. (This is similar to the way an email program registers to receive mailto: links.) This allows the same solution to be used by users on their desktop that they are using on their smartphones. When any website offers an SQRL code the user just clicks on the code with their mouse cursor and the locally installed SQRL app will pop-up, prompt for their SQRL password, confirm the domain, and then log them in.
I'm not sure why some people made this assumption, as it seems obvious to me that this would not be the case. The SQRL master key is protected about the same way you'd protect a password database: with a strong master password. Stealing a user's phone would not automatically give you access to their online identity unless you also had their master password. More details on key management are explained in the page on SQRL Client-Side Key Management on SQRL's website.
This is also false. SQRL provides a built-in way to allow the genuine account holder to update their login credentials in the case of a compromised key. This feature is known as Identity Lock:
“Identity Lock” prevents identity change & allows recovery: This is also significant enough to deserve its own detailed description page: “The identity lock protocol” (page 4 in the link block at the bottom of this page.) Once a user's identity has been established with a web server, the SQRL client is unable to change that identity. This means that if the worst happened, and a very weak and easily guessed password was used, or a user's phone or desktop was hacked to obtain their identity master key and password, no malicious third party can change the user's online identity to lock them out of their own online accounts. And, moreover, by then loading an a normally offline “Identity Unlock Key”, the true owner of their identity can retire and replace their lost or stolen online identity to essentially take it back from any attacker, rendering their previous identity useless.
Okay, so this is actually partially true. When using SQRL by scanning a QR code, there is indeed very little protection against phishing. Unless the user is careful to ensure that the website shown in their browser's URL bar is the same as the one displayed by the SQRL Client app, they could be authorizing a login session for the attacker. This is still better than passwords, where they'd be giving the phisher permanent access to their account (and any other accounts they have elsewhere which share the same password) until they change their password, but not as good as other solutions which integrate with the user's browser like U2F keys, WebAuthn, client certificates, and (under certain conditions) password managers.
However, when you're using an SQRL client on the same device that you're logging in with, SQRL does have some protections against phishing in place. These protections are explained on SQRL's website, under the section on How SQRL Can Thwart Phishing Attacks. There's also the possibility of integrating SQRL with browsers (possibly through plugins) to provide much stronger protection against phishing attacks; on-par with solutions like WebAuthn and client certificates.
Overall I'd rank SQRL on about the same level as password managers for phishing protection. It has the potential to provide strong protection against phishing when installed on the same device the user is logging in on, but provides minimal protection when installed on a different device.
Now let's compare SQRL with existing widely-used authentication solutions.
SQRL is vastly superior to passwords in many ways. Not only is it more convenient to use once set up, since users don't have to worry about remembering or retyping multiple different passwords for each site, but it also protects against password reuse, weak passwords, keylogging, and, to some extent, phishing.
Disadvantages SQRL has compared to passwords are that it's more difficult to implement for website operators, not as widely-used, requires more time to set up initially, requires some effort to transfer to a new device, and provides a single point of failure for all the user's accounts if the master key is stolen (though this last point is also the case for passwords if a user uses the same password on every site).
In many ways, SQRL is very similar to password managers. They both provide a single, centralized trust anchor which serves as a sort of authentication proxy between users and individual services. There are a couple ways though that SQRL is superior to password managers.
The main advantage I think SQRL has over password managers is that it's easier and more secure to use on untrusted or only partially trusted computers. For example, say a user wants to login to a website using a computer at a public library. With a password manager, he would have to either access the password for that site on his phone and retype it into the computer manually, or download his password manager and password database onto the library computer, unlock the database using his master password, then log in. The first scenario is inconvenient for the user, and exposes the user's plaintext password for that one site to the untrusted computer (and to any malware on the untrusted computer, including keyloggers). The second scenario is even worse, as it's both inconvenient, and exposes the user's entire, decrypted password database and master password to the untrusted computer. With SQRL, the user would only have to scan a QR code on the untrusted computer's screen, which is much more convenient for the user, and only exposes a single login session (with no reusable credentials like a password) to the untrusted computer.
Another advantage SQRL has over password managers is that it's easier to recover from the worst-case scenario: the user's password database / master key being stolen. With a password manager you'd not only have to change your password on every site, you'd also have to worry about the attacker changing your passwords (possibly locking you out of your account). The attacker also has the advantage of possessing a list of all the sites you have an account on, making exploiting the theft of a password database that much easier. With SQRL, having your master key stolen is still a terrible situation to be in, but the attacker has no list of sites you have an account on (having to instead guess), and cannot change your password to lock you out of your account. Once you load your identity unlock key it's also a bit more convenient to change your login credentials on each site, as the SQRL client has the ability to do it for you automatically for each site you visit upon login. (No need to go through any "change password" forms.)
Finally, I think SQRL has one small but important advantage over password managers in regards to its goal of replacing passwords entirely, and that is that sites have the option of enforcing use of SQRL over traditional passwords. So long as users still have the option of poor security, reusing the same password on every site, that is something that will still happen. If SQRL starts gaining widespread adoption, sites can actually start phasing out the use of passwords. That can't be done with password managers, as they rely on the the use of passwords in order to work.
In terms of disadvantages, I actually can't think of a situation where SQRL would necessarily be worse than password managers in terms of security. The main disadvantage SQRL has is that it requires support from website operators, whereas password managers require no special support from existing services. This means you can start using password managers right now, but SQRL will have to wait until sites implement it before it can be used. This is a significant barrier to adoption.
The primary advantage SQRL has over client certificates is one of convenience. Client certificates are currently complicated to set up, difficult to transfer between computers, and have privacy issues when the same cert is used on different sites. While theoretically we could build a system using client certificates which would solve these issues, there would also be the problem of poor integration with website UIs and web servers, which are more difficult problems to solve. I won't go into too much detail here, as there's already an excellent article on the usability issues of client certificates on browserauth.net.
In terms of security, client certificates have the disadvantage of requiring the involvement of a CA. This is (potentially) expensive, and requires trusting the third party CA. Furthermore, if you choose to ignore CAs and instead self-sign your certs, you have the issue of certificate revocation to deal with. Client certificates also have the same security and convenience issues as password managers when users want to log in on an untrusted computer; they have to transfer their cert to the untrusted computer, which is both inconvenient and potentially exposes their master identity to malware on that computer.
In short, until someone comes up with a better, user-friendly solution using client certificates which solves (at least most of) these problems, I don't believe client certs are a serious competitor to SQRL (or, for that matter, to passwords).
Just thought I'd mention this: SQRL and 2-factor authentication are not mutually exclusive. SQRL is a replacement for the first factor in 2FA: passwords. Other additional measures like OTP codes or FIDO U2F keys can still be used with SQRL.
Now here's where things get interesting. WebAuthn is a new (well, newer than SQRL) W3C standard designed to provide a standard API websites can use to authenticate users with public keys on the web. Just like SQRL, it supports using the user's phone to authenticate a login session on an external device, in addition to a few other authentication methods (such as 2nd factor security keys).
This is where SQRL finally meets its match, at least from a security perspective. Not only does WebAuthn provide all the same protections against password reuse, weak passwords and keylogging that SQRL does, but it also provides even stronger protection against phishing by integrating with the user's browser even when authorizing a login session for a PC the user has not previously set up the authenticator's client software on. This is possible because in that situation WebAuthn communicates with the user's browser directly using two-way communications protocols like Blutooth or NFC instead communicating with the website the user is using via a one-way QR code.
From a usability perspective, things are a bit more complicated. On the surface at least, WebAuthn wins again. Because it is a W3C standard which already has implementations in multiple browsers, in theory users can immediately begin to use WebAuthn without needing to install any third party software. In practice though, most existing WebAuthn implementations focus on its use as a form of second factor authentication, or as a way of re-authenticating a user who previously signed in on the same device via a different login method (usually a password). As a primary authentication factor, WebAuthn is still rather lacking in viable implementations.
Other minor considerations include the fact that SQRL has a built-in method for rotating the keys of accounts in the event of a stolen master key, whereas WebAuthn relies on websites to implement their own system for revoking keys, and the fact that WebAuthn requires certain optional hardware (like Bluetooth or NFC) in order to authenticate to a remote machine, whereas SQRL can work on any machine with a working display.
Overall, I think it's very likely that WebAuthn will eventually render SQRL obsolete. SQRL may have a bit of breathing room for now, but WebAuthn has much stronger backing from browser vendors, site operators, and other third party organizations (like the W3C). Once WebAuthn gets a couple implementations enabling its use as a primary authentication factor, I expect it will begin to take over the web very quickly.
SQRL is still under active development, so the material presented in this answer is subject to change. As development continues, I expect that some of the vulnerabilities and uncertainties in this answer will be addressed. Most of the discussion is currently taking place on the SQRL newsgroup over at grc.com.
SQRL is a convenient solution to the problem of the username/password paradox. (i.e. the convenience/security tradeoff) without using a third-party. It provides a simple alternative to the most popular authentication model (Username & Password), with virtually no compromise to security. It is practically just as secure of any of the common authentication models used today, so long as you are still security conscious. If you are using SQRL, it doesn't mean you can't follow best security practices such as combining this with multi-factor authentication for important accounts.
It is important to not the miss the point of SQRL. SQRL itself does not necessary provide better or worse security. If the computer/phone itself gets compromised, or the user is tricked into being phished, then this is a side-channel attack instead of a direct fault of SQRL itself. Every conventional authentication method has this problem of side-channel attacks The unbreakable one-time pad is also vulnerable to side-channel attacks such as the compromise of the pad itself, or bad surrounding security or implementations.
If you listened to the original proposal of the idea on Steve Gibson's podcast, followed by the Q&A's, many of the concerns raised on this stack thread have been answered. Also, Steve said so himself that this very "simple" and "ingenious" (his words) idea would need to be "vetted" and "hammered on" by security experts as only time will tell if this is a secure solution.
In conclusion, most of the arguments against SQRL fall outside the domain of SQRL itself, and instead are problems with humans practicing poor security. SQRL doesn't introduce new classification of problems that our traditional authentication methods already don't have.
SQRL is excellent if used appropriately by people who are security conscious. You must understand that there is always a trade-off between convenience and security, and this solution is probably the best balance of the two I have seen.
I agree with the other comments to certain degree, but I do think there are some merits:
To enable SQRL for you, you have to create your master key and store it on your phone. DONE. From that second, you will be able to log into ANY website that uses "SQRL". And that would be an anonymous login - as long as you decide to not provide any further information.
That is MUCH easer than working with your own certificate; or creating explicit user accounts (probably asking you to provide a valid email address). Maybe I would not use that same master key for my banking, amazon, ... accounts - but especially for these "i would like to post something here" situations ... perfect. No more "please let google or facebook or whatever site know that you want to post here".
SQRL provides no ground breaking improvements. QR codes are an optical barcode format useful for short content distribution - nothing more.
Any "auto-login" situation that SQRL is trying to solve could simply use a client certificate stored on the mobile instead.
Hypothetically a QR barcode on a HTTPS page could return a server signed or encrypted version of the client certificate (or a similar credential) as previously known by the server, but why? For credential expiration? The site could simply reject an expired credential directly.
So the biggest security problem I have with this protocol is: Reinventing the Square Wheel.
Update
Reading new answers and comments, I'd like to point out how easy it is do something similar to SQRL through simple automation of mature existing technology:
HTTP 403.7 - Client Certificate Required or a vanilla 403 error. <s403l ref="https://www.example.com/S403L" />)The "mobile" and "visual" nature of SQRL is something of a misdirection as it doesn't provide detached two-factor authentication and you now need two computers to navigate the internet instead of one. Unless you point your desktop's USB webcam at its own monitor.
The trade-offs between passwords and certificates is well defined in the security community: Passwords fit in a human brain; certificates don't fit in a human brain (usually) but can have crazy entropy and good PKI management features (expiry, revocation, policy extensions, etc). SQRL fits cleanly into neither camp; and if it's drifting towards the less-human more-computer camp as it seems to be - it has years of development and security analysis to repeat existing X.509 features.
Type 40-L QR barcodes could dispatch/store the 1KB X.509 client cert if desired.
Commented
Oct 11, 2013 at 10:13
I would like to address the first question: "one of the problems that I can think of is if the QR reader is compromised, to display www.google.com instead of www.nsa-super-secret-place.gov/123":
The master key is used as the seed into HMAC together with the website address (FQDN). So although the QR code may encode completely different URL the protocol will NOT reveal the authentication code that would normally be sent to www.google.com (in the example).
Second, many of the contributors forget about the key objectives when working this idea out:
I believe the protocols addresses these in full!
However, there are compromises that actually come from the the first obectjive. If no 3rd party is involved in the authentication, how can one revoke their authentication details? Additionally, the security of the master key is an obvious concern. I envisage this to be well protected by future mobile devices in a HSM like chip. Until then, the key is just a file pin mobile device, protected by a password, though PBDKF2 ensures that it is very slow to actually brute force it.
