IT Security 
IT Security Meta
This blog post is inspired by a question on Information Security Stack Exchange about two weeks ago. The question seems to have attracted quite a bit of attention (some of it in an attempt to defend the flawed scheme) so I would like to write a more thorough analysis of the scheme.
Let us start by discussing the current standard for authentication. Passwords. No one is arguing that passwords are perfect. Far from it. Passwords, at least passwords in use by most people are incredibly weak. Short, predictable, easy to guess. This problem is made worse by the fact that most applications do not store passwords in a secure fashion. Instead of storing passwords in a secure fashion, many applications store passwords either in plaintext, unsalted or hashed with weak hashing algorithms.
However, passwords aren’t going anywhere because they do have several advantages that no other authentication scheme provides.
- Passwords are convenient. They do not require users to carry around additional equipment for authentication.
- Password authentication is easy to setup. There are countless libraries in every single programming language out there designed to assist you with the task.
- 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.
So, let us compare Steve Gibson’s SQRL scheme against the golden standard of password authentication. Long, unique and randomly generated passwords hashed with bcrypt, scrypt or pbkdf2 in addition to a one time password generated using the HOTP or TOTP algorithms.
(I am going to be borrowing heavily from the answers to the original Information Security Stack Exchange answer since many excellent points have already been made.)
Disadvantages
Authentication and identification is combined
No annoying account creation: Suppose you wish to simply comment on a blog posting. Rather than going through the annoying process of “creating an account” to uniquely identify yourself to a new website (which such websites know causes them to lose valuable feedback traffic), you can login using your SQRL identity. If the site hasn’t encountered your SQRL ID before, it might prompt you for a “handle name” to use for your postings. But either way, you immediately have an absolutely secure and unique identity on that system where no one can possibly impersonate you, and any time you ever return, you will be immediately and uniquely known. No account, no usernames or passwords. Nothing to remember or to forget. Your SQRL identity eliminates all of that.
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.
Single point of failure
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.
So how is this master key to your online life stored? On a smartphone. Not exactly the safest of places what with all the malware out there targetting iOS or Android devices. You have bigger problems if you are using Windows Phone or Blackberry. 😉
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”
Not exactly very reassuring.
Social Engineering attacks
@tylerl has a very good point about this in his answer. I don’t see a way for me to write it in a clearer way to I will quote him verbatim.
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.
Conclusion
The three major flaws I have pointed out is definitely enough to kill SQRL’s viability as a replacement for password authentication. The scheme not only fails to offer any benefits over conventional methods such as storing passwords in a password manager, it has several major flaws that Gibson fails to address in a satisfactory manner.
This blog post has been cross-posted on http://www.infosecstudent.com/2013/10/debunking-sqrl/
Filed under Authentication Password Uncategorized
Tagged: authentication, password management
If you find both of the following true:
“Passwords are convenient. They do not require users to carry around additional equipment for authentication.”
Then you are using weak passwords.
“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”
This is just not true, there is nothing about SQRL that disallows another method of identifying you. SQRL can replace the username/password associated with a user account, it doesn’t have to replace the whole concept of a user account. I have seen a lot of blogs that require you to create an account, then do absolutely nothing with that data. That is the only case where scanning the SQRL code would be the only step. Any other time a site needs more data would still have to ask for it, including an email and/or “security questions” if they want to provide account recovery to their users. SQRL would still allow you to log in without the username/password hassle. Attacking SQRL for not doing more than that is a straw man since that is not what it is designed to do.
Similarly, pointing out that SQRL is no less vulnerable than passwords to social engineering is not “debunking” it since that is explicitly not a feature. As far as I can tell it is no more vulnerable than current options.
The real question about SQRL is the single point of failure/juicy target issues. Can this be adequately secured on a notoriously insecure platform (the smartphone)? I lean towards no, but I think it’s at least worth thinking about and don’t think anyone actually addresses what they’re doing to try to secure it in the StackExchange question.
SQRL is a new technology, a couple of weeks old, with no concrete implementation (as far as I know). The fact that it was published before any code was written is a clear sign to me that the technology should indeed be scrutinized before more work is done. Saying that it’s “debunked” or “dead on arrival” is a bit too far, at least at this point. Everything can change, specially if real flaws are discovered.
Now, to address the points you’ve mentioned:
In a traditional username/password scenario, there’s also no possible way to recover access to an account should the password be lost. The only possible way is to ask the user for his email address (or his home mail address, or his mother’s maiden name, or …). This is exactly the same with SQRL. A provider can ask the user on a second step for his email address, as a way to recover his account should his key be compromised or lost. The fact that most websites requires the username to be the email is a “convenience” (or inconvenience, as I see it), to overcome this “second step”.
I’m not sure I understand this point. The smart phone is not an integral part of SQRL. It’s an example of an agent to act in between the user and the website. It has been said already that it could be a browser plugin, or a desktop application, or a smart phone. In all of those cases, it’s up for the agent to secure the data and it’s up for the user to back it up. Just like a password manager like LastPass would. I trust that LastPass would encrypt my data safely, just as much as I would trust a SQRL app on my smart phone to do the same. And I backup my LastPass data, just like I would with a SQRL app. So, again, this problem also exists for the common “password-based authentication” scheme.
I guess it’s needless to say that this happens a lot with password-based authentication and was never mitigated. On my bank’s main page there’s a huge banner saying that I should not enter my password anywhere, except when I explicitly go to their website to check my account. Can the bank do something to prevent this kind of problem? No, not with password-based authentication. This point has been improved in SQRL during the last weeks since the original announcement, in that the provider has now the chance to send the URL of the “next step” after the login screen. So, an attacker trying to fish users to provide keys for his bank account would cause the user to be directed to the bank itself upon login, not the attacker’s website. So, it seems you are a bit outdated on this and seems like a huge advantage to me against password-based authentication.
All in all, if those three points are enough to kill SQRL, then logic says that it’s also enough to kill password-based authentication, no?
What I personally like about SQRL is that it allows users to create secure and unique tokens (“passwords”) to login to different websites, without the hassle of remembering long/secure passwords. It’s also not needed to say that a major problem we have today is that our users are reusing the same password over and over again. And most of the times, it’s a very weak password. While you and me might be using a password manager to create/store/remember the unique and secure passwords for our online accounts, most of the users out there are not doing that, as it’s either too complicated or inconvenient to them (or expensive, if they want to use it on their phone). If they could just easily use an app that would allow them to securely login into a website, I’m all for it.
As a final note: I’ve hinted before that this is a “tech preview” in the form of a series of webpages suggesting how a new authentication scheme might work. As it’s common with all new technology, flaws do exist, but the fact that no code was released and the fact that the author has explicitly called for opinions and for pointing out flaws is a huge advantage in my book.
To be clear, this is the reason most of us take anything SG says with a very large bucket of salt:
http://attrition.org/errata/charlatan/steve_gibson/
I say what anyone says with a very large bucket of salt. But you have outsourced your arguments to that website which, in my humble opinion, is a giant waste of time.
But I don’t intend to fight over what you said. Instead I will offer a link as well, where readers can see Steve Gibson’s daily video podcasts.
Then choose for yourself.
Someone is not /just/ right or wrong. Usually it’s a bit of both.
http://twit.tv/sn/
This sounds like a complaint against non-password sign in systems in general. I don’t think Gibson ever proposed removing passwords entirely. This, like OpenID, is a technology which allows you to sign in very quickly without having to use a password, but unlike OpenID, google can’t log in as you anywhere you go (this being stack exchange, you are probably using OpenID now). If you really want to use a password on a website supporting SQRL, then that is still an option. I don’t see anything wrong with that.
I think the master key does represent a single point of failure.
When registering a separate username/password combo at each website, forgetting a password is resolved via a password reset at that website. No other website logins are affected.
If you lose your master key, say your phone got smashed, your identity has been lost for all sites, not just one. You’d have to contact every online store you’ve dealt with to re-associate your account with a new identity token. Perhaps this will spur associated online services that can act as identity restoration brokers.
Additionally, while not a security weakness, merely forgetting you phone at home will leave you unable to access online resources.
These risks can be mitigated, but only through prevention.
I hope SQRL or something like it succeeds and gets us beyond usernames and passwords. Will wait and watch.
A different strong password for every site, requires the use of a password safe. This too is a single point of failure so not much different from SQRL.
You should be able to store a backup copy of your master identifier on a thumb drive or even a piece of paper. This might be able to be used securely on a trusted platform in the case where you forget your smart phone. Also, a smart phone left at home generally is a pain already. I’ll turn around and get mine if I forget it.
The master identifier could be on more than one device. It is stored under strong encryption. The loss of the device should not be a factor (assuming you have a backup). Just like a password safe you will have one strong password that you type in order to use your identity.
SQRL is a method of authenticating a user for a Login action. If this proves fruitful, the approach can be applied to other actions online as well, and that could get very interesting. For example, how about mobile payments, simply by scanning a QR code.
Security around the method is one thing. I think the harder problems lie in securing the elements in play, namely, the master key, the phone itself, and not only in the face of being compromised but also in the event of unavailability, as when forgetting your phone at home, the battery runs out, gets dropped in the toilet, or crashes due to some ill advised jailbreaking attempt.
If the phone is to become your single access broker to everything on the internet, it has to be secure and available. I’m not sure how a phone can ever be as available as a password stuck in your head, but maybe that’s the direction things are going. Make sure you bring a portable charger!
There isn’t anything stoping someone from using unique SQRL keys for each site.
People don’t typically do that. They reuse the same password or forget and recover passwords at a common email or use a password manager. Each of these is a single point or multiple points of failure that are as easily exploited if not easier.
They are for the most part more vulnerable because the QR code issued is only good for one session while each master password entered into a phishing site would be good until revoked.
I’m sure these posts predate the revocation scheme that Steve has mentioned recently. So I’ll ignore those criticism.
How is SQRL substantially different from FIDO?
http://www.fidoalliance.org/how-it-works.html
Microsoft et al are not in it?
Hows the debunking going? Seems SQRL has moved on since your orginal article, possibly addressing your concerns. Maybe its time for an update.
I’m a user experience designer with an interest in human factors in security. While I’m not qualified to judge the technical merits of SQRL over other authentication methods, the assertion that “long, unique and randomly generated passwords” are part of a “gold standard” of security betrays the underlying reason why the design and implementation of security-related systems is in such a sorry state today. I would go so far to say that the author of this post is in fact a cause of the problem, and can offer no solutions at all. Here’s why:
It is demonstrably wrong to make people take on the work of ensuring their own security by having (amongst other things) to remember long and different passwords for every system they access. Doing so has encouraged people to seek workarounds that do the opposite of what is intended. Passwords are today anything BUT convenient when used in what the author insists is “the right way”. We need to kill off this condescending attitude towards idiotic end users who don’t understand what’s good for them.
It is counter-productive to delegate “security” to a technical priesthood who constantly chant that it must be applied as strongly as possible in all situations in which identity or data are involved. It prevents ordinary people developing a practical understanding of risk and the trade-offs between applying different levels of security in return for other advantages. For example, I should be given the choice to have NO security if the situation might warrant it. I should be able to consider what that means in the context of what I’m trying to do. To constantly deny my that by insisting on long passwords and the mysterious paraphernalia of retrieval questions, non-unique user names and email address verification is hugely damaging to the way people interact with online systems, not to mention the people who operate those systems.
The wider issues of security and identity management in the digital age, and how ordinary people navigate and establish a culture around those issues are only just becoming clear to us. The attitudes demonstrated in this post are not helpful. They will not solve any of the underlying causes of the problems the author professes to care about.
I welcome SQRL. The sooner we understand that digital security is about people, and not technology, the better.
This is a brilliant write up! As a technical person, it is wonderful to know there are others who understand that not all users are technical and the user experience of password authentication is horrible for everyone. People use technology. Technical people and non-technical people. Some tools, such as a programming language, presuppose technical knowledge. A mobile app that provides access to documents stored in cloud services does not. I just want my documents.
Another alternative: https://www.autosign.me/
Not really, as that seems to work by a central site, holding your private key.
The security implications of the proposed authentication method are one thing. The way Gibson “sells” this is another.
Steve Gibson did not invent this, and he does not own any IP in this. It seems as there are several patents that protect this kind of authentication method. According to this guy (http://www.michael.beiter.org/2013/10/04/steve-gibsons-sqrl-is-not-really-new/), this protocol is neither new nor public domain, and one should do a legal evaluation as well as a more thorough security evaluation before using SQRL.
Seriously, if Gibson doesn’t even do prior art research before blasting out “his” idea, how much time did he actually invest in the security of it?
Hi, Anderson. Ad homenim attack aside, Steve did mention some prior art related to SQRL back in https://www.grc.com/sn/sn-424.htm. At the bottom of the transcript you’ll find this:
Tom: …The point of this is all of this stuff, as Steve just mentioned, is already available, free and open source. It’s just putting it together and making it work. And hopefully some patent squatter doesn’t try to come along and claim they invented it. But that’s always a risk with anything you do on the Internet.
Steve: I did look at what Google had done, because of course when I came up with this I thought, wait a minute, how can nobody have thought of this before?
TOM: Right, right, uh-huh.
Steve: And so I spent a couple days really looking hard.
There could be patent protected prior art that Steve didn’t find. He has a few patents of his own but he’s not a patent lawyer: he’s mostly a technology person.
Remixing existing technologies and ideas into something new is still something new.
You can ask any information you want from a user when you create the account, SQRL doesn’t prevent you from collecting emails, physical address or anything you want. And typically for commenting on a blog you would want a unique display name. And you should typically not use the public SQRL key as the primary key for your users (which would be like using a user’s password as a primary key).
Your first two objections are really the same (Authentication and identification is combined, and Single point of failure). It is clear that the weakness of this system is that it relies on a single key and if that key is compromised, all hell breaks loose. But it relies on the idea that it is easier to protect a single key that should never leave a user’s mobile phone (except to have one offline (if not physical) backup copy of that key at home in a safe place). And ideally that this key resides in a locked down environment (iPhone), with an encrypted disk, hardware enforced unlock password plus an additional level of crypto within the app. It is true that if all of these fail, the system collapses. But intuitively I would expect it to be far more secure than passwords.
Password managers are only practical for people who only ever access the internet from a single machine. And they do not offer more protection over the sort of scenario where SQRL would fail, i.e. if someone cracks your password manager, he has access to all your accounts like he would on SQRL (accessing the SQRL key is exactly equivalent to accessing the password manager master key). In both cases you have no other choice than to reset your account on every single website one by one.
The same can be said to your third objection. The SQRL website claims that if offers a protection against phishing attacks which I disagree. But that is no different from any password based attack. In fact it is marginally better as the attacker would only gain access to a session, not a permanent access to the website, more akin to a session cookie theft, which I agree doesn’t help much.
But keep in mind that most people do not use password managers, and even fewer use only website specific passwords. And computers are far more easily breached and have way more untrusted code running than modern mobile phones, so moving your key to that platform is rather a good thing. I don’t think SQRL can claim that it brings security to a level that will beat any intelligence agencies, but it does look to me far more superior than password based solutions.
There was a lot of garbage written in this piece as well as in the comments. 1. SQRL does not represent a single point of failure. You could generate a different private key for each site if you wished to. The single master password model is just a suggested way to use SQRL.
SQRL is far less vulnerable to social engineering than a password. If a password can be remembered by its user then it can be coerced out of them. No one can remember an SQRL private key. Passwords can be captured by keyloggers, SQRL keys cannot.
The one point about SQRL no one mentioned and the reason it is far more secure than a password, the SQRL private key is never sent anywhere. The server encrypts a random string with the SQRL public key. This can only be decrypted with the SQRL private key on the users computer. The decrypted string is then sent to the server to prove the user is the owner of the private key.
SQRL is not “new untested technology” The SQRL protocol just uses existing public/private key technology in a better, more secure way than it is currently used.