Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

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?

share|improve this question
    
Cleaned up the comments - far too much nonsense and fud to be acceptable here. –  Rory Alsop Jan 26 at 21:40

6 Answers 6

up vote 13 down vote accepted

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.

Gibon's rubbish

  • 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.

share|improve this answer
1  
@WayneWerner this is true, if most developers were drunk 12 year olds from the 1800's that still believed in the magikal power of unicorns and happy thoughts. –  AviD Oct 10 '13 at 15:31
8  
"If you're following good password practices" is a huge caveat, and most Netizens don't do it. Part of SQRL's promise is to reduce users' need to stay on top of best practices. Further, the SQRL spec will call for the master key to be stored encrypted with a master password and will be impossible to brute force (tuned to take ~60s for one try). Getting the password will often be non-trivial since SQRL promotes out-of-band authentication (ie, keylogging a hacked machine won't always help you). So while the consequences of full compromise are high, the likelihood of compromise is somewhat low. –  spiffytech Oct 10 '13 at 17:43
15  
SQRL may yet have flaws that need addressing, but it claims to solve a number of problems found in existing approaches to authentication, and any criticism of SQRL that asserts it "offers no benefits" should include rebuttals of these claims instead of expecting the assertion to be blindly accepted. –  spiffytech Oct 10 '13 at 17:44
8  
> Like anything that comes out of Gibson, this SRQL scheme is highly flawed and offers no benefits over conventional methods. --- This doesn't seem to help answering the question, and I actually feel that you have problems with the technology because of who came up with it. Some of the points you mentioned as flaws are actually addressed by the "spec". For instance, SQRL itself doesn't mentions how the master key is stored, but Steve Gibson's comments about it are that a mobile client, for instance, would encrypt it with a master password using a scrypt that takes 60s on average to execute. –  jpkrohling Oct 11 '13 at 9:19
4  
Gibson explicity addresses the protection of the master key. –  Mark C. Wallace Oct 11 '13 at 10:42

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:

Advantages

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 succeptible to phone-related attacks. More on that later.

Disadvantages

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 posesssion 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.

Alternatives

The most problematic aspect of this scheme is how poorly it compares to the available alternatives.

The most secure 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.

Finally, 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.

TL;DR:

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's Updates

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.

A Better Solution

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.

share|improve this answer
2  
And about the third point: the same happens with most users that don't use a password manager, by simply using a single username/password in several websites. Or, with users of password managers, whose "identity" is spread on several websites, but stored in one single location (LastPass' servers, 1Password database, and so on). So, it's not really a SQRL flaw. All in all, the more I read about SQRL, the more I see the benefits of it comparing to the current alternatives. Say that you say about Steve Gibson, but SQRL really seems like a good alternative to me. –  jpkrohling Oct 11 '13 at 9:33
3  
"The caution already beaten in to the heads of users regarding password security does not necessarily translate to new authentication techniques like this one. . ." This is an excellent point, and the battle has already been lost to marketing. QR codes are seen as an easy way to get things done, not as a potential attack vector. Username/password pairs at least were FIRST used as an authentication mechanism, not a marketing tool. –  Jonathan Garber Oct 11 '13 at 13:51
2  
@jpkrohling: With regard to password managers, I would guess that most users of such software do NOT store their master password on their mobile device, precisely because they are aware of how dangerous that is. I have one physical copy of my master password in a secure location, but no electronic copies. The attacks that would grant access to my master password are different from those that would compromise a site password, and are far less likely. (Primarily because attacking my password database would involve attacking me personally, rather than a large compromised site.) –  Jonathan Garber Oct 11 '13 at 13:59
2  
@jpkrohling Neither LastPass nor KeePass stores a master password anywhere. It's used to unlock your password database, but it isn't stored. This is fundamentally different from having a single key which is, itself, used everywhere. –  tylerl Oct 11 '13 at 16:55
1  
@jpkrohling WRT redirecting the user to the correct site on authentication: this is fundamentally impossible with SQRL because authentication is out-of-band. You'd instead need a browser plugin or some other client-side agent to handle the redirect, which then defeats the whole purpose of having a QR code. –  tylerl Oct 11 '13 at 16:57

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".

share|improve this answer
1  
I'm not sure that this is much of a valid point - if you're going to allow anonymous logins then why bother with a login in the first place? A simple captcha would suffice to prevent some spam. –  Wayne Werner Oct 10 '13 at 14:57
2  
Because the anon login is YOU, just declining to provide any information about your identity; nobody can spoof it. –  Ross Presser Oct 10 '13 at 16:02
    
It sounds almost like a half-baked re-hash of Windows CardSpace. –  Xander Oct 10 '13 at 16:23
    
I didnt realize that my posting actually pointed out the REAL problem with SQRL: it opens up the door for massive spaming. You see - a new user just needs to log in using SQRL. Conclusion: you still need a "registration" process; afterwards SQRL might be a nice convenient way to log into certain web sites. –  Elton Oct 11 '13 at 7:36
    
Or a captcha, if you are logging in an user which has never logged in before. –  jpkrohling Oct 11 '13 at 10:11

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:

  1. anonymity by not using 3rd party
  2. ease of use
  3. no need to type secret credential on untrusted computers

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.

share|improve this answer
1  
Again,what's new about this idea? It seems to me to be a primitive variation on the now defunct Windows CardSpace. –  Xander Oct 10 '13 at 20:10
    
Yes you are right about CardSpace. Then there is U-Prove also owned by Microsoft. The question is how would you use CardSpace or U-Prove on a computer that you do not trust (internet cafe or friends computer). That is what Steve added. –  Vladimir Jirasek Oct 10 '13 at 20:28
2  
Ah, ok, that's what I was missing. I still agree with @TerryChia that this is a non-starter without a revocation mechanism for the user keys. –  Xander Oct 10 '13 at 21:03

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:

  1. Website asks any CAPTCHAs or similar "I'm a human" verification. Once the user has complied (POSTed), the website returns a HTTP 403.7 - Client Certificate Required or a vanilla 403 error.
  2. Custom 403 pages are easy enough to setup and can be quite pretty and user friendly. Could even bootstrap the functionality required below in a manner similar to the "Adobe Reader required" prompts on many websites.
  3. Custom 403 page includes some markup that a custom browser plugin reacts to. Let us call this custom plugin 'S403L compliant' in the spirit of 'SQRL compliance'.
  4. The S403L plugin generates a standard client certificate, which is secured in the usual encrypted browser cert cache (or a third-party cache if your browser's keystore encryption sucks). The plugin creates a standard CSR for the client cert and sends the CSR to the URL specified in the 403 markup. (e.g. <s403l ref="https://www.example.com/S403L" />)
  5. The S403L compliant server use the user's session_id (retrieved from cookies or query string) to create continuity with Step 1 and then returns the CSR as signed by the server. General server authentication will accept any client certificate that was signed by the server (and thus met the registration criteria demanded in Step 1).
  6. The S403L plugin stores that signed client certificate in the browser's cache. From then on, the standard browser without plugin assistence can "auto-login" into the server in the standard SSL/TLS fashion until the certificate expires.

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.

share|improve this answer
    
> could simply use a client certificate stored on the mobile instead. --- except that this technology exists for years both on mobile and desktop, and it's not as widespread as one would wish. And opposed to the client certificate, SQRL doesn't requires you to prove your real identity to create a "SQRL Identity". If you so wish, you can create as many identities as you want. This means that the advantage comparing to Client Certificates is that you have anonymity from the auth protocol's side. –  jpkrohling Oct 11 '13 at 9:25
    
@jpkrohling It is a common misconception that client certificates require identity disclosure to use. That is a requirement of commercial signing authorities to use their globally interchangeable trust chains. In practice a client cert can simply be an anonymous CSR created by the client and signed by a specific server, after meeting whatever criteria are desired (CAPTCHAs, prior account, etc). Certificates can also have a built-in expiration. Type 40-L QR barcodes could dispatch/store the 1KB X.509 client cert if desired. –  LateralFractal Oct 11 '13 at 10:13
    
Ok, true, my bad. From this perspective, the client (mobile app, for instance), could be generating a client cert for each website that the user is registering. This sounds more expensive than hashing some information, but could be an interesting solution. In any case, I still don't agree with your claims that SQRL is worse than useless. –  jpkrohling Oct 11 '13 at 10:25
    
I was perhaps harsh on that wording and will remove it. But I don't see SQRL as anything other than more sexy way to distribute negotiated client credentials; and one that hasn't resolved some of the subtle problems addressed by mature authentication schemes. A password manager is tedious (I don't bother with browser integration because I'm a paranoiac) but I know that only I and one website share each one-shot password in my encrypted key-store. I don't have to worry about fancy new hash/auth schemes, just the quality of the PRNG/TRNG that my password manager uses to generate passwords. –  LateralFractal Oct 11 '13 at 10:35
    
Well, that's the difference. You are not the usual case (neither am I, or anyone on this website, I suppose). Common people use the same password over and over because generating random unique passwords is too complex for them. A "more sexy way" to generate random unique key that can be used for logging in might be the difference here, provided that they are as secure as the current best practices while being more convenient. –  jpkrohling Oct 11 '13 at 10:58

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.

share|improve this answer
    
Thanks Ansichart. But can't existing auth solutions simply retain equal or superior security features to SQRL and then use automation to increase their user convenience? What fundamental property of SQRL's user convenience is not due to automation? I ask because if a user has two black-boxes that do the same thing; one labelled "Mature" and the other labelled "SQRL" and they can be both engineered/automated have the same interface/buttons on the outside of the box - what added-value does SQRL provide? –  LateralFractal Oct 12 '13 at 4:06
    
It solves the problem of the password paradox without having to use a third party. –  ansichart Oct 12 '13 at 4:20
    
I see. So if someone doesn't want the 3rd-party risk of single-sign-on and won't generate/store their passwords with a password manager, SQRL can step up. But if SQRL is a mobile black-box which asks for a password to unlock the master key used to regenerate/store SQRLIDs and then perform back-channel linking of client's cookie/QR session_id with server's recorded SQRLID to login - how is this a different mobile black-box from a mobile password manager with auto-login via the same back-channel; or a two-party mobile client cert plugin with auto-generation & login via the same back-channel? –  LateralFractal Oct 12 '13 at 4:41
    
I have done some major editing of my original post after some second considerations and closer reading to what others have been saying, as I may have over-hyped it. I suppose having the mobile phone being the central key shifts the problem, and would would make it more important to have stronger security on your phone. Steve Gibson also brings this up in the Q&A podcast. –  ansichart Oct 12 '13 at 5:36

protected by Adnan Oct 10 '13 at 23:18

Thank you for your interest in this question. Because it has attracted low-quality answers, posting an answer now requires 10 reputation on this site.

Would you like to answer one of these unanswered questions instead?

Not the answer you're looking for? Browse other questions tagged or ask your own question.