Today I'd like to discuss an article that always comes up in Google when searching for SQRL. Debunking SQRL on the Security Stack Exchange Blog.

I find it disheartening that an article that frankly has a lot of misleading "facts" is ranked high in Google, and I was hoping we could discuss about improving or removing it, so to prevent misinformation.

(If you don't believe me, check out the comments on that article).

Passwords are convenient. They do not require users to carry around additional equipment for authentication.

No they aren't. Secure passwords are anything but convenient. If your passwords aren't secure + you aren't using additional equipment for authentication (namely, multifactor authentication), then you are easily compromised and we can stop the discussion there.

Password authentication is easy to setup. There are countless libraries in every single programming language out there designed to assist you with the task.

Well, of course. The specs are still being finalized and discussed. That said, there are already libraries and clients for SQRL in various languages. (nodejs, PHP, Java, various implementations and clients). So again, that claim doesn't really hold.

Most importantly, passwords can be secure if used in the right way. In this case, the “right way” involves users using long, unique and randomly generated passwords for each application and that the application stores passwords hashed with a strong algorithm like bcrypt, scrypt or pbkdf2.

True, on the other hand, password-based systems are very very easy to get wrong. Storing a password in plain text is a lot easier to be aware of and learn than using a strong cryptographic hash with a salt and a good cost parameter.

Not to mention that the user has the use a secure password (or be forced to, which is poor UX) for the whole system to be worth anything.

What Gibson describes as an advantage to his scheme I consider a huge weakness. Consider a traditional username/password authentication process. What happens when my password gets compromised? I simply request for a password reset through another (hopefully still secure) medium such as my email address. This is impossible with Gibson’s scheme. If my SQRL master key gets compromised, there is absolutely no way for the application to verify my identity through another medium. Sure, the application could associate my SQRL key with a particular email address or similar, but that would defeat one of the supposed advantages of the SQRL scheme in the first place.

Again, wrong. There's nothing in the specs forbidding a service to provide other means of authentication in case your SQRL path is compromised. Just like Stack Exchange allows you to link multiple credential sets to your account (so that if your Google account is compromised, you can still access the site through your Facebook account, and unlink Google from your account). This is still very possible with SQRL.

The proposed SQRL scheme derives all application specific keys from a single master key. This essentially provides a single juicy target for attackers to go after. Remember how Mat Honan got his online life ruined due to interconnected accounts? Imagine that but with all your online identities. All your identities are belong to us.

The example does list a smartphone as where your private is stored. But that's not in the spec. The client can be a smartphone, the user's own computer, a linux server in Sweden, or a Raspberry Pi with a client on in. Also, if you use a password manager (which you do, because if you don't, you're either a savant which, you know, good for you, or your passwords are insecure to begin with)

If my LastPass master key gets compromised, the same "All your identities are belong to us" crisis is to be expected.

People also have the tendency to misplace their smartphones. When combined with the previous point of no other means to identify yourself to the application, this would be a very good way of locking yourself out of your “house”

Well, when people start realizing that their phones hold a lot of information about them, information they don't want to "misplace" or have fallen into the wrong hand, they'll keep better care of it. Also, SQRL does give you the ability to backup your key for a rainy day.

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.

I read this, and I ask myself if the writer has read the SQRL spec (or even just the example)

If falsebank.com provides me with a login QR code taken directly from bank.com, my client will send a login request to bank.com, not to falsebank.com. If falsebank.com shows me a QR code for falsebank.com, they learns nothing about my relationship with bank.com, so I really don't understand the point being made here.

I apologize if I hurt anyone, but that article is one big misinformation. That's not to say that there aren't flaws with SQRL (namely, if you lose your private and haven't backed it up. This weakness also applies to master keys found with password managers, so we haven't made the situation any worse).

I want to ask we remove that article, because it

  1. is misleading
  2. ranks high on Google searches for SQRL
  3. reduces the site's reputation with actual experts.
  • 7
    Actual experts don't like SQRL. Seriously. Zero. Actual experts don't consider Gibson to be one of them.
    – tylerl
    Jul 18, 2015 at 5:05
  • I agree with most of the points in this post, but phishing is in fact a concern with SQRL. (At least, when you're using it by scanning a QR code. When integrated with the user's browser, it actually does have strong phishing protection.) If falsebank.com displays a QR code taken from bank.com, and your SQRL client sends a login request to bank.com authorizing the login, fakebank.com will have a valid login session for bank.com. It's no different from you scanning a QR code displayed on someone else's computer and authorizing the login.
    – Ajedi32
    Nov 8, 2015 at 5:57
  • @Ajedi32: Why would they have a valid session? My request is sent against bank.com, and my session is domain bound to bank.com. Cookies are not shared between domains... Nov 8, 2015 at 5:58
  • 1
    @MadaraUchiha Your login request is sent to bank.com, but it's authorizing a login for a QR code obtained by from bank.com by falsebank.com's servers, not by your browser. falsebank.com's back-end has the cookie for the session you're authorizing.
    – Ajedi32
    Nov 8, 2015 at 6:01
  • 1
    @Ajedi32 Right, got it. That is a very good point and a rather fatal flaw. (You're the first to convince me by the way, thanks for that). Nov 8, 2015 at 6:03
  • @Ajedi32 Wait, isn't it trivial for the server to not authorize the login request if it doesn't come from the same IP who requested the QR code? Nov 8, 2015 at 7:33
  • 2
    @MadaraUchiha It is, and in fact that's exactly what SQRL does. However, that only works when your SQRL client is on the same machine that you're logging in on. If you're using SQRL on your phone (by scanning a QR code) then it's expected that the IP that requests the QR code will be different from the one that authorizes it. (Since your phone will often be accessing the internet through 4G.) It also doesn't protect against attackers behind the same NAT as you. (Such as on public WiFi.)
    – Ajedi32
    Nov 8, 2015 at 14:26
  • @Ajedi32 Right, didn't think of that. Thanks again! Nov 8, 2015 at 14:27

2 Answers 2


As discussed in chat - the Sec.SE community, which is the expert community in this field on Stack Exchange, disagrees with your points 1 and 3, and agrees with point 2.

  • 1 - The article is logical and describes why the proposed solution is flawed.
  • 2 - This article ranks high on Google searches for SQRL
  • 3 - Increases the site's reputation with experts

So the article will not be removed.


As for the convenience and other factors about passwords or SQRL, I don't find either system particularly compelling. But for phishing, this is something that I find to be a very serious issue.

I'll spare you all the technical details, but the basic issue is that SQRL is strictly out-of-band. Your identity is your phone, your phone cannot communicate with your browser. The website can communicate with your browser, and the website can communicate with your phone (both directly and by sending QR codes), but the browser never gets to deliver the phone the browser's verdict about the TLS session. So the security of the user's TLS session doesn't factor into the authentication step, and therefore authentication can be subverted. In other words, phishing can and will happen.

SQRL is fine for situations where authentication isn't important -- situations where it doesn't matter if your account gets compromised. Situations where you'd be happy using the word "passw0rd" as your password. But if security matters, then SQRL is not for you.

If you want to see an example of authentication done right, then look at the U2F security key created by Google. Remember that bit about browser integration? For U2F, the browser (this is built in to chrome) communicates directly with the USB hardware and tells the USB token what website it's on after verifying the website identity through TLS. That becomes part of the key exchange, meaning that it is literally impossible to authenticate on a phishing page. This means that phishing isn't just "hard" or "unlikely" or "complicated" -- phishing is impossible.

Gibson almost got this right, but he made a typical amateur error in failing to understand the attack model. He makes the website identity part of user identity, but the website doesn't need to be authenticated to the browser. So a phisher can take a valid QR code from the real site and show it to a victim using an invalid phishing page. The victim authenticates, and the attacker gets logged in. I'm sure Gibson could have gotten it right if he had more experience in designing security protocols. But as these go, the error is too deeply baked into the protocol, and it can't be salvaged.

  • Note that integrating SQRL with the browser is totally possible and hasn't been ruled out by the spec. Also, SQRL is meant to be a replacement for passwords, not for 2FA systems like U2F. It's possible to use SQRL and U2F, just as it is possible to use passwords and U2F.
    – Ajedi32
    Jan 19, 2016 at 20:32
  • @Ajedi32 Adding browser integration to SQRL is possible, but it's unlikely and not currently planned. Were it to ever happen, much of the design and architecture of SQRL would become irrelevant. So we'll go with what we have for now.
    – tylerl
    Jan 19, 2016 at 23:23
  • I don't know... local device authentication is already part of the spec. I don't really see browser integration as much of a stretch. (Seems like an implementation detail to me.) I think a lot of people seem to overestimate just how important the QR code bit is to the SQRL spec. The website even says: "If you imagine a future where SQRL login is widely available [...] for the most part your laptop, desktop, or tablet client will likely receive the most use." Implying that most people will actually be using local device auth most of the time.
    – Ajedi32
    Jan 20, 2016 at 2:11

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .