Usernames and passwords have been with us for a very long time, and many people think that their time has come and gone. I won’t rehash here all of the digital ink that has been spilled all over the Internet on the topic, but it is clear that a system that requires both a user and a server to share a secret--the password that goes with a username--has proven to be fatally flawed in the modern age. One major problem is the sheer number of passwords that any moderately active Web surfer has. Your only options are to insecurely reuse a few strong passwords; use easy to remember weak passwords; or use a password manager like LastPass, 1 Password, or any of the other myriad products.
And the nail in the password coffin is the near-weekly announcement of yet another hacking event that resulted in the loss of millions of login credentials, a failure of servers to keep their part of the secret. (If you haven’t already, I’d advise you to check out Troy Hunt’s have I been pwned? Web site and check out his blog post about the whole mess.)
Sure, two-factor authentication helps a bit with the security of user names and passwords, along with other proposed and implemented fixes. As often as not, those solutions simply add yet another potential point of failure when implemented poorly and increase the inconvenience of an already burdensome system on users.
Usernames and passwords are the shaky foundation of our security, and will be with us for a long time yet. But we’re long overdue to find a more secure and convenient replacement. One that is convenient and easy to use for all users, not just geeks.
Enter SQRL
SQRL is the Secure Quick Reliable Login system, pronounced “squirrel.” SQRL is “a comprehensive, easy-to-use, high security replacement for usernames, passwords, reminders, one-time-code authenticators . . . and everything else.” The last part is a bit bold, but SQRL looks to be an interesting proposal that would pretty much eliminate the need for usernames and passwords. It was invented by Steve Gibson of Gibson Research Corporation (GRC), of Spinrite hard-drive recovery software, the Security Now! podcast, the ShieldsUP! port scanning service, and various other free security tools and information fame.
The basic way that SQRL works is to present the user with a QR code that the user can either click or scan with a mobile QR reader. In either case, a client SQRL app--either a browser plugin or a mobile app--reads the code to provide the secure authentication service. The client then decrypts a secret master key, which it uses to generate a site-specific public/private key pair based on the master key and the site name. It then signs transaction tokens with the private key and provides the site with the public key so that it can authenticate and identify the user. After site registration, on all subsequent times the user goes to the site and authenticates, the SQRL client will use the same identifier so that the site knows that it is you and not someone else. Best of all, because the key is based on the site URL, it can’t be shared with any other site, adding an element of privacy.
The SQRL client is protected by a strong master password, the only one you need. But this password is never transmitted to any site and is not used as part of site authentication, so remains secure.
One nice feature of SQRL, one that will help in its adoption and acceptance, is that it can be used side-by-side with usernames and passwords as a transition strategy. The figure below shows how this can work; I captured this image from Gibson’s SQRL demo page. The user can click or scan the QR code, or enter a traditional username or password. If you visit the page, you’ll need a SQRL client plugin or extension installed and configured before you can authenticate with SQRL. Gibson has created a Windows client, and there are other implementations that other people are building for many platforms. There is a very out-of-date ASP.NET MVC implementation that hasn’t seen activity in a year; I’ve been trying to contact the developer to possibly kickstart the project, but so far without luck.
I don’t have nearly enough room here to explain SQRL, but you can find all the details on Steve Gibson’s Gibson Research Corporation’s SQRL pages. SQRL fanboi Ben Cooper has created a nice SQRL - An Illustrated Guidesite that lays out how it works in a format more approachable than the GRC pages, although in lighter detail. And there is a growing body of resources available for SQRL.
A caution about other SQRL resources you’ll find with a GoogleBing search: Gibson originally proposed the idea in a series of three Security Now! podcastsback in October 2013. The specification has aged and matured significantly since then as he and the security community hammered on the details, turning it into something much better, secure, and convenient. There was a flurry of discussion about SQRL in online articles, blog posts, and forums after the announcement, many of which raised valid issues, most if not all of which have since been satisfactorily resolved. So be careful of any writings earlier than late 2014; they are all based on an out of date specification and certainly didn’t have the benefit of even a proof of concept implementation.
There are a lot of details to SQRL. I urge you to explore the links and resources I’ve included in this article before judging whether it is a worthy technology. So far, in this very early stage of implementation, it seems solid, but only time will tell if the implementations, particularly on the client side, can be streamlined and simplified enough for non-geek users to use effectively. And just how seamlessly SQRL can be integrated on servers.
It will take some time for any username/password replacement technology to gain acceptance, but SQRL seems to have as good a chance as any. We need something!
