Security

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.

Privacy2_610x426.jpg

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 as ShieldsUP! 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:

squrl.png

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.

About

Patrick Lambert has been working in the tech industry for over 15 years, both as an online freelancer and in companies around Montreal, Canada. A fan of Star Wars, gaming, technology, and art, he writes for several sites including the art news commun...

26 comments
waltzie
waltzie

I really does not understand why reinvent the Well and SQAURE !!!!

Challenge/Response based on secret is OLD and already standardized (see OCRA1 - OATH)

use a QRcode to upload data ..is just an input method.

I does not see any real advantage.


Walter

kyber
kyber

I am a little confused by some commentators who are concerned about the use of an app (whether on a smartphone or desktop/plugin) as I can infer they probably do not use a password app at the moment and I am wondering how on earth they can possibly create and remember different long random strings of passwords without an app. Surely they cannot just be depending on their mind and memory given the sophistication of cracking tools, the power of cheap gpus, and the extensive availability of comprehensive rainbow tables (which hold the hashes under multiple recognised and security tested algorithms of all words in all vaguely common languages be they regular words, pet names, substitution schemes, and various concatenation including all birthdates, and published phrases).  

wzis
wzis

If you use the SQRL app on your PC, since steal your app from your PC is not difficult once hacker gained access to your pc, now the security only depends on the master key for the app, that could also be stolen, so this is dangerous, since after that the hacker gains all the web site access as you which you use the app to access.

twilightxone
twilightxone

not an ultimate rocket science, upto those who like it or adopt it.

But nothing can do what your brain does ... put everything on your phone and then run for it whenever you need to log into some website on your desktop ... what if the mobile phone goes out of power and you are sitting in a library or some airport ... if the mobile app is everything, then wait for some security app to protect your mobile or backup your data / QR apps into another smart phone in the closet ... 

bmerc
bmerc

Step 1: Steve Gibson "invents" something new that actually has been around for years

Step 2: News media climb all over themselves to be first to announce this "innovation."

Go to Step 1:



ramriot
ramriot

Apologies if this has already been said.


Patrick you made several mistakes in you description of SQRL that has introduced nonexistent security holes which others who also did not read the full protocol description at grc.com/sqrl so let me explain:


1/ "How it works":

 a) The 256-bit "Blob" (Master-key) is protected at rest in the app by being encrypted using a 'memory-hard' algorithm and an app password that needs to be typed in as required to release the key for use and takes on average 1 second to unlock (used to slow down any brute force attack on the app or an extracted master-key).

b) On master-key generation a copy is encrypted with similar algorithm that takes approx 60 seconds to lock/unlock and exported as a printed QR-Code that you file away, just in-case you lose your phone. This is required, but if a user fails to backup the protocol or its inventors can hardly be held responsible, that is the responsibility you take if you want a true 2 party security protocol.

c) SQRL code recieved from a website includes some random and state information that is never repeated so a replay attack is NOT possible using a passive MITM attack. You seem to be confused here as you say both replay attack is possible but in the same paragraph say exactly the opposite.

d) The public key is sent back to the website with a signature of the whole QR-code generated using the private key NOT an encrypted version of same as that would not be a proof of identity. A signature can be validated by the public key to show you have the corresponding private key without reveling said private key.

2/ "Naysayers"

e) The deterministically generated public private key pair are NOT stored in the phone, they don't need to be as they can be regenerated each time you authenticate.

 f)  MITM, you are correct SQRL as it presently exists (things are still fluid) does not protect from an Active MITM attack, but then nothing else really does, that is unless you have either a trusted 3rd party and/or some trusted certificate information pre-existing for each end. If does though prevend several types of passive MITM and phishing scenarios by use of out of band authentication, url / IP confirmation, timestamp validation etc.

One point you completely fail to mention is that SQRL can be used Anonymously as an alternative to all those annoying sites that need to collect private information just for the purpose of posting a comment (THIS SITE ALSO).  Unless you expose your master-key your SQRL public key for a site is in no way related to you as a real person.

Also I'm glad you still like it, and I agree many Social Networking sites have a vested interest in providing 3rd party solutions for this, BUT in the current climate of Secret FISA warrants to companies that they cannot even confirm or deny they have been issued with, NSA snooping on networks upstream of major service providers, massive collection and storage of metadata (That as you say storage makes a tempting criminal target). I am thinking we need something that is 2 party, open protocol, open source and independently validated. SQRL is right now a good start at getting that.

 Finally although all of the published stuff on SQRL talks about smartphone, tablet and PC apps, there is no reason why an physical token cannot be made that encloses the protocol, all cryptographic tools and all keys in such a way that to use the master-key without knowing the passphrase would require removing the encapsualtion on the individual chips and using an electron microscope. Similar to how existing RSA Tokens do now, but without haveing to share a secret key with a 3rd party or paying a per-use fee to host it on your server.

eclypse
eclypse

Just seems clunky as hell to me. Hey, let me unlock my smartphone, fire up an app, possibly do some other annoying step here, scan a code on a monitor, then put the phone down, then do all that for the next website. Did I miss something here? Much faster than typing in a username and password. Yeah! Where do I sign up?!?  

And what about a username/password isn't intuitive?

Adam_12345
Adam_12345

" First, your identity for every site resides in an app on your phone or on your desktop."...and that's a major flaw, but how about creating hash (MD5 etc) on that data that stays unchanged on your device and proves your identity? Then you could compare the result of hash function and make yourself sure that your data is the same.

knopfler1980
knopfler1980

What could it happens with this authentication proposal if you store that private key in your phone? Could it be stolen or hi-jacked with third party apps? 

Kind regards

333239
333239

How does a smartphone/QR code provide any more security? I know you don't need to use one, but I would say that if you do, it even weakens the system, as people could use your phone to access your sites when you are not there. Yes, your phone can be password protected - many just have a 4 digit code that is easy to watch someone entering, so that is considerably less secure. If you have a longer password on your SQRL app then how is this better than any of the other password-remembering systems? It is just another take on PGP.

ccfman2004
ccfman2004

I am one of those people who don't have a smart phone.  The cell phone I have is good enough for phone calls and the occasional text (if it works).


The desktop app would have to work on many different OS's like Mac and Linux.

rolandvanrijswijk
rolandvanrijswijk

Although this is a different approach, the idea is far from new. There is a fully open source, open standards compliant system available called "tiqr" (https://tiqr.org/) that has been around since the end of 2010.

nynymike
nynymike

Gluu has implemented support for TIQR, an open source QR code authentication mechanism developed by SURFnet, the higher education federation in the Netherlands. QR code has good usability... its fun. There is no license fee for passwords, so having new mechanisms where the IP is not proprietary is a huge service... we should thank the authors for making the Internet a safer place. Gluu would be very interested to implement support for this in our open source SAML and OpenID Connect authentication platform. For more info on that, see http://gluu.org  Also, if you want to see a blog on how to implement strong authentication using freely available mechanisms, read http://www.gluu.co/.icn4  I need to add update it for SQRL...

DarCK
DarCK

The QR code can be compared to the website address to prevent man in the middle attacks. Though phishing attacks would still get through human verification on the phone based app.

pankaja_us
pankaja_us

The Secure QR Login still doesnt provide with the confidence that it is really secure. Seems like there is a security hole. For e.g. if a bank website implements this then how will it verify that the person who is using the app is a valid customer with the master code (which is stored in the app) and a generated QR code each time. Anyone could be posing as the customer and use the app. I am not convinced in relying on the stored codes in one app and worrying about the security yet again.

admin
admin

As cpetit notes in point 1, this does place a responsibility on the user to backup and prudently manage their master sqrl identity. I'd simply point out that this is inherent in any system which cuts out a trusted third party. Either we trust another entity to keep us (our identity and our data) safe, or we accept that responsibility ourselves.

As for point 3, recognizing the importance of keeping this master identity secure against theft or abuse, the proposed solution is to have the sqrl master identity *deeply* encrypted on the phone, so any attempt to export the identity itself involves a memory-hard problem that takes no less than 1 minute, making brute-force attacks impractical. A lighter-weight version of this would be used to authenticate the user (one second vs. one minute) to prevent impersonation. So there's still an element of "something you know" as a second-factor to prove to the *device* that it's us. 

james.allen is correct that a desktop client precludes the need to have a smartphone. The user has the choice whether to authenticate "in-band" with a local client or "out-of-band" by scanning the QR code.  

As carefully as I've tried to choose my words, I'm not a security or crypto expert so I won't be surprised if I've made minor mis-statements in my reply above.  So I'd strongly advise anyone who's interested in this to lurk (or participate) in the GRC newsgroups where the details of the sqrl specification are still being actively discussed and developed. 

cpetit
cpetit

There are 3 major problems with this authentication method:

1. As the author observes it is completely dependent on what you have (i.e. a 256-bit secret blob on your smartphone).  If you ever lose it, or your smartphone is damaged, and it's not backed up, it fails.

2. Anyone who doesn't have a smartphone (I don't know how many people don't, but I'd guess there are quite a few people who don't) can't use this authentication method.

3. If someone else gets your smartphone, they can act as you very easily.  How many normal users password protect their smartphones? 

I do agree it is an interesting method and minimizes the danger, assuming you don't lose or damage your smartphone.


waltzie
waltzie

By the way... it's just a "challenge/response" where response is used to generate an authentication token. (key pairs)

The authentication token is used to encript/hide authentication informations

In any case the security level is based on "secret" where is stored and how it's assigned/delivered, exactly as it work with old One Time Password devices.

 


email
email

@bmerc Agreed - it is quite unacceptable how  Gibson "sells" this "idea" of "his" and how the security community falls for it.

Gibson did not invent the protocol. However, not owning the idea does not hinder him to generously give it away to everyone as an "open and free solution, as it should be". This protocol is covered by several patents (http://www.michael.beiter.org/2013/10/04/steve-gibsons-sqrl-is-not-really-new/), and apparently only a few people in the security community do the due diligence and point this out.

Anyone using this without paying royalties to the original inventors is asking for trouble. There is need for a new and secure authentication standard that is open source, but I don't think that SQRL is it.

DT2
DT2

@eclypse You missed the part where you have to wait for the advertisement to run before the app lets you log in.

avsmithy
avsmithy

@eclypse If you are on your own PC you can use an app/browser extension. That way you can simply click on the QR code and the app will authenticate for you. For PC's that you don't trust (e.g. at the library) you can use your phone.

Benvdlei
Benvdlei

@333239 Bitcoins uses QRcode on a very save way and there is already a POS app www.nuvopos.com with paymaent options with QRcode very easy to use

FTAdmin
FTAdmin

@ccfman2004 

iPod? Tablet? Also, if this gains serious traction, I wouldn't be surprised if someone develops a cheap device along the lines of an authenticator key chain.


(My apologies, if this double-posts. --Way too many scripting hands in this pot for my taste.)

james.allen
james.allen

A correction on your second point. A smart phone is not required to make this work. Checkout Steve's documentation by Googling GRC SQRL.

Editor's Picks