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
- is misleading
- ranks high on Google searches for SQRL
- reduces the site's reputation with actual experts.