Debunking "Debunking SQRL" - Blog article is misleading

Question

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.

Answer 1

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.

Answer 2

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.