SQRL: A new method of authentication with QR codes

Will a new authentication method using Secure QR Login (SQRL) for websites finally end the user name and password standard? Here are the pros and cons. 

Usernames and passwords are how most of us identify ourselves to almost every website around the net. For a long time now, security researchers have been looking for a better way. Traditional authentication just isn't that safe or intuitive. In particular, passwords can be stolen from a database or by a man-in-the-middle (MitM) attack, a keylogger, or even brute force. Worse still, people end up having to remember a different password for each site they visit if they want to be safe, and often forget them. Various systems have been introduced to help make this process more secure, including two-factor authentication and third-party login services from Facebook, Twitter, Microsoft, and Google, notably. However, these systems also have flaws. Two-factor authentication can be annoying for users to deal with, while third-party login services rely on a third party, so if your Facebook account gets compromised, all of the sites you log in with that username will also be compromised.

Steve Gibson is a known security enthusiast and is behind many projects online such asShieldsUP! and the Security Now! podcast. He can be a controversial figure, but in the past few weeks, he has introduced a brand new authentication system which is starting to gain traction, and approaches the login issue from a completely different way. It's called SQRL, or Secure QR Login. From the user's side, it couldn't be easier. A site that implements this system would simply present a QR code, and anyone who wants to log in would scan it with a phone app, or a desktop app, and then the site would log them in. No username, no password, nothing to type in. From the user's point of view, it certainly solves the friction issue of other systems. But is it really better than a username and password?

How it works

On your phone, a SQRL app would contain a secret 256-bit blob of data. This would be your randomly generated secret code, which is never divulged to anybody else. The QR code itself would contain a URL, including the domain name of the site you're trying to connect to. When you scan the code, your app would create a public and private key pair from your master key and the domain name of the site, using an HMAC hashing function. Then, the app would communicate with the site directly, sending the public key as your identity (the equivalent of a username), and the encrypted QR code as your authentication (the equivalent of a password). Since your master code, the secret blob of data, never changes, the resulting public key wouldn't change either. That means the website would know it's you. And by encrypting the QR code of the site with your private key, the site can verify that you indeed possess the matching private key, without actually having it, thanks to the beauty of public key cryptography.

Here's how Steve Gibson visually explains the process:

There are a lot of advantages to this system, which may be why it has started to gain traction since it was first introduced a few weeks ago. First, it's a really simply system, which means there is less friction for the user, and there are less chances that bugs would be introduced in the apps. Users can use a single master secret code for every site, and then password protect that code, so that they would only need to remember one password, yet the authentication would be unique for each site. Even if a site gets hacked and your public key for that site stolen, that doesn't allow attackers to impersonate you anywhere else. Another big advantage is that it doesn't rely on any third-party service. You aren't giving up control of your identity for multiple sites to Facebook or Google.

Naysayers

Of course, not everyone thinks that this is a good idea. When the news hit Reddit a week ago, there were more than a few naysayers. First, your identity for every site resides in an app on your phone or on your desktop. That creates a major attack point, and could also be lost if not backed up. Anyone that is security conscious would realize that and take proper measures, but many people probably wouldn't. Existing systems such as LastPass provide the same benefits to the users, having a single master password to control their identities on many sites, but since it's cloud based, it's a lot more foolproof. If you lose your phone, your cloud data isn't lost as well. After all, sites wouldn't all have password reminder services if they weren't getting used all the time.

Another issue that's been raised is that this doesn't solve proper MitM attacks. If an attacker actively listens to your connection and can see the data going through, then they can do a replay attack and still get in, like they would with a username or password. It does provide some protection, because there is no risk that the password may have been reused on another site, and since the QR code changes at every session, the public key and encrypted blob that's transmitted wouldn't be reusable later on.

Still, Steve is confident that this is the best system for authentication so far, and many others seem to agree with him. SQRL will be discussed in a panel in an upcoming HTML5 developer conference. Many people are also busy making SQRL apps for smartphones and desktops. And many people have been giving feedback through Steve's site, Internet forums, and security podcasts. Whether it goes anywhere will mostly depend on whether popular sites implement SQRL, and that's where it may end up failing. The whole point behind third party authentication services is so Internet giants like Google and Facebook can know more about us and control more about our online experience. SQRL is great for the user, especially those who are security conscious, but it does nothing for these websites. In the end, users go with what is offered to them, and right now the apparent winner currently pulling ahead seems to be Facebook Connect.