Posts Tagged ‘authentication’

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/

According to Rory Alsop’s post the most popular topic at our IT Security site is passwords.  So in this post I’ll provide a tour of some relevant questions and answers, and a look at how it sparked further investigation of the sorry state of password protection in some current systems.

There is an amazing amount of confusion, disinformation and bad practice out there with respect to password management.  This is all the more frustrating because the basics were worked out back in the dark ages (1978 to be precise) for Unix by Bob Morris and Ken Thompson (Password Security: A Case History, Morris & Thompson, 1978). They not only covered the importance of hashing passwords with salts and a slow algorithm, but they described what is now called a “pepper” (a second salt stored apart from the password database).

So if you peruse the dozens of ‘passwords’ questions you’ll find frequent reference to the basics.  We’ve also tried to summarize some of the key points in the ‘passwords’ tag info.  By the way, that’s one of the cool things about StackExchange sites in general – how they provide for a little “wiki” for each tag, to allow us to put key information just a mouse hover or one click away from readers.

Of course even among good practitioners, there are debates about the finer points, and that is another thing you’ll find here.  See e.g. the spirited conversation about highly iterated password hashes for web apps vs the risk of DDoS attacks at Do any security experts recommend bcrypt for password storage?.

In the end, you’ll often find that the right approach depends on what kind of “security” you’re looking for.  As our Frequently Asked Questions points out, this depends on context – what assets you’re trying to protect from what sorts of threats, how your different vulnerabilities compare, and how that all fits into your business plan.

I’ll end with a look at one question which demonstrates the kind of expertise we have already attracted to the site: MySQL OLD_PASSWORD cryptanalysis?.  I asked this after stumbling across some other questions about how MySQL used to deal with passwords.  To my amazement, within hours, noted cryptographer Thomas Pornin had not only cracked the old algorithm, but he included some code to demonstrate just how totally broken the OLD_PASSWORD scheme was.  Subsequently we also found a paper from 2006 with more details.  Evidently the folks at Oracle who work on MySQL hadn’t gotten the memo then, and still have a lot of work to do to improve their current scheme, as described at Looking for example of well-known app using unsalted hashes.

So stay ahead of the crowd: when you have a question about security, see if we have a good answer.  If not, ask away.  And if you see questions that need more work, please contribute to providing good answers!