A few times every decade we get to witness the emergence of a truly revolutionary back-end technology breakthrough. I recall following OpenID in the mid-00’s, reading some of the early discussion groups and blog posts, eventually watching it become supplanted by OAuth. Which would go on to drastically simplify the way most people log in to websites. I wonder if we’re witness a moment like that right now with the Simple, Quick, Reliable Login (SQRL) protocol.
SQRL is a decentralized website login and authentication protocol released last week after over half a decade of work, by security researcher Steve Gibson. It is a protocol that functions like a combination of OAuth and a password manager. Like OAuth, it enables a 1 button (or QR code) login process, simply click an “authenticate with sqrl” link and you’re in. Like a password manager, it is an app that lives on your phone, desktop or a browser extension.
Unlike either of those solutions, the process that occurs in the background after you hit “authenticate” and before you’re logged in is where really groundbreaking stuff happens.
SQRL is client-side authentication, meaning an SQRL client (on your phone, as desktop app or maybe a system service in future) negotiates with the server to validate your authentication. Let that sink in for a second… you don’t tell the server who you are or what your password is, the server ostensibly communicates with your phone to figure out who you are. The nuts and bolts of this system are complicated/technical and I’m not actually sure I fully grasp it at this point. But I do know this has the potential to be huge.
A Short List of Benefits
The client-side approach has several unique advantages and eliminates many of the problems with the current username/password schema:
The server does not store your password (zero-proof)
Not only does it not store your password, the server never interacts with your password in any way. We all know websites really suck at keeping your passwords safe and secret and reusing passwords in 2019 is extremely dangerous. With SQRL only the client app has a password (and it’s highly encrypted).
The server does not know who you are
As far as the technical spec goes, the server does not need a username, email address, facebook id, google account, etc to identify you. It only needs are random public key.
In practice, it a website my ask you to provide a username, but because of the pseudonymous nature of SQRL, the site would have no way of knowing that “ohryan” means “guy who write on ohryan.ca” who is also @ohryan on Twitter.
You can’t be tracked
Because SQRL generates unique public keys on a per domain basis, the protocol does not enable cross-site tracking in the same way as something like OAuth does.
Your identity can’t be hacked
A centralized system like a password manager or an OAuth provider lives in the cloud, so there is always a remote possibility of a massive breach exposing your master password on any given service. With SQRL, your identity stays in the client which is in hardware in your pocket, not one central source that every hacker in the universe can target.
It’s open
SQRL is an open standard. Anybody can create a client, with any additional bells, whistles and improvement they want (including addressing some of the security concerns I talk about below). Apple/Windows/Google could add native OS support. The world’s smartest security researcher can all contribute to the project, write server-side implementations, etc, etc.
Some Concerns
In my opinion, based on my understanding of the protocol today, SQRL has one really big problem and a few smaller problems.
Major Concern: No Deauthorization Mechanism
Simply put, if you lose control of your SQRL identity (say your phone is stolen) the protocol has no way to invalidate the authorizations you’ve given to websites with the stolen identity. It has no way to block an attacker from accessing those sites with your stolen identity (assuming the attacker also has access to your phone password and your SQRL client password). The protocol does have a really robust set of mechanisms to retrieve your identity (including something like the bitcoin paper key system), so you will ultimately not lose access to those sites. But the way the protocol is setup, it is only once you access the site with your recovered identity that the site will learn to distrust your old identity.
Unlike Oauth, where a password reset triggers deauthentication across all previously authorized site. With SQRL, you would have to manually visit each authorized site to deauthorize that stolen identity.
So in this way, SQRL actually behaves somewhat like a password manager. If you lose a device that contains access to a 1password library you’d be similarly screwed. To be 100% secure, you would have to manually reset the passwords on all the hundreds of sites you’d stored in your password manager. Fortunately, in both the cases a thief is unlikely to knowledge of your master password. I just feel like this is a real concern that the Gibson dismisses or doesn’t take as seriously as he should.
Minor Concerns
Phishing is sorta trivial
Since SQRL depends on the user being able to scan arbitrary QR codes to gain access to a site. It’s conceivable to imagine a scenario in which a bad actor could impersonate your bank, create a fake SQRL QR code at www.mybankk.com, hope you don’t notice the misspelling and then subsequently ask for your banking info and steal all your money once you’re in.
The thing is, OAuth is vulnerable to this same type of phishing attempt. A creative bad actor could spoof the entire “sign in with google” process and if the user is not paying close attention to domain name, then the user would be clueless about the spoof.
Hell, I bet there are chat logs between me and notian discussing this very thing when OpenID first started bubbling up.
To my knowledge these types of phishing attempts never materialized against OpenID or OAuth (though I could be wrong).
At worst SQRL is no worse than the status quo. At best SQRL clients may be in a unique position to improve this situation (though there idea to harden SQRL against this attack by using IP addresses is a non-starter IMHO, but I won’t get in to that here).
Malicious Clients
Since SQRL is an open standard any random bad actor could create a malicious client to do malicious things, like stealing your password.
The best solution to this problem is to make the “official” the best possible app, such that the poor quality, slapped-together nature of malicious apps will be obvious. Unfortunately, I’m afraid this will require a real development investment and it’s not clear anyone is willing to pick up the tab.
The project has a long way to go to get there, but then again, it’s essentially day one.
New paradigm
This final concern isn’t really a problem with SQRL as a protocol. It’s more that… We’ve had decades of trying to teach mom & pop how to use usernames and passwords safely and it’s really not going very well. Getting them to adopt a brand new paradigm is going to be hard.
Final Thoughts
First of all, if you’re read this far and you haven’t tried it out. Do it now. Grab on of the apps and try logging in to the official forms at https://sqrl.grc.com/. It will blow your mind.
SQRL seems to be the password solution I’ve always wanted. The concept of decentralization seems inherently right and good, it feels like the natural state of the internet. Decentralization by way of having an on your phone store the sensitive data and do the hard computation, just makes, so, much, sense.
It’s hard to say where this technology will end up. I know Gibson is seen as a bit of a fringe wonk in some circles. I’m very interested to see what real security experts have to say, both about the implementation as well as the underlying crypto.
If it’s as good as it seems, this could be huge.
Further Viewing/Reading
