SQRL Poised To Save Us From Password Hell

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

DIY Internet: More on personal VPNs

A few followup thoughts regarding Monday’s post about setting up a personal VPN.

Self-Sufficient, DIY Internet

All the Facebook Cambridge Analytica nonsense has really emphasized how dependent we have become on third party services and social networks.

As I thought about it, the idea of being self-sufficient online has really started to appeal to me. I mean this blog has always been independent, fully controlled by me. As a web developer with fully-stack devops ninja experience, I have all the skill and experience I need to set up any sort of web service I want.

So when I thought about the reasons for using a VPN regularly and the likelihood that I’d have to pay for a decent service, I wanted to see if i could do it myself. On severs I own.

I think there are more opportunities to DIY online, to rely less on dubious third parties.

Peace of Mind

As I alluded to in my first post, the real world security threats associated with public wifi are only a minor concern. I’m not generally too concerned, most of the time.

That said this little icon next to my WiFi connection gives me such a massive sense of security and piece of mind. The fact that it auto-connects without me having to take an action is just the icing on the cake.

Censorship

Streissand is an anti-censorship tool designed to bypass draconian government censorship like China’s Greatfirewall. You don’t live in China, do you really need do worry about censorship? Probably — and if you hang around the right subreddits — increasingly so.

Canada’s telcos are presently lobbying for a censorship regime. Perhaps the first draft targets content most of us would agree is “bad,” but who knows what the next version will look like.

Even if you’re less paranoid, there’s a good chance your workplace or school is filtering some content. Maybe it’s not content you bump in to very often. But if even if they are not filtering traffic, they’re almost certainly collecting your web traffic. That’s something I’ve never been too comfortable with.

A VPN allows you to take back your online freedom whenever you’re using a work, school or any other network that distrusts you.

Bypassing Geographic Restrictions

In case you missed, VPNs allow you to bypass geographic content restrictions. When you use a VPN, you traffic originates from the IP address of the VPN server. And since cloud providers host servers in many physical locations, you can easily bypass any geo restrictions based on IP address.


If you missed Monday’s post you can read it here:

How to: Set Up A Personal VPN

How to: Set Up A Personal VPN

Skill Level, Novice: To set this up you’ll want to be mildly comfortable with the command-line. But you won’t necessarily need know (or care) about the technologies involved.


Way back in 2010, firesheep scared my pants off. I was traveling for work when it dropped and I became acutely aware of just how vulnerable my data was on huge airport wifi. In the 8 years since then  https everywhere has become a reality and the threat of bad actors sniffing your web traffic is nearly a thing of the past.

But I’m still paranoid. And today I finally did something about it.

Enter Streisand

Streisand is an open-source project with the goal of defeating censorship. The best way to defeat local censorship is secure, undetectable VPN connection (usually in a foreign country). The goal of defeating censorship aligns nicely with the goal of hardening your internet connection.

Streisand is essentially an installer for a set VPN tools which you’ll install on a cloud hosted server that you control. The project presently supports Amazon EC2, Azure, DigitalOcean, Google Compute Engine, Linode, and Rackspace. You simply run a few commands, select a few options (the defaults are totally fine) and Streisand does the rest.

If you’ve ever run apt-get or setup homebrew on MacOS you should have no problem setting this up. Streisand’s installation instructions well written and easy to follow (jump right to the instruction here).

Much to my surprise — unlike many of these types of command-line driven projects — I ran into absolutely zero issues during the install.

It gets even easier.

If that doesn’t sound easy enough — get this — Streisand copies over an HTML document with an incredibly easy to use guide, per-filled with all the configuration settings your need for your server. It’s dead simple to share this with anybody you choose.

Bonus points: Auto-Connect on public WiFi.

The last time I used the TunnelBear app, I noticed an advanced setting to auto-connect to all wifi except for a whitelist of trusted network. So that if you’re on your secure home, work or other trusted wifi network, you don’t waste VPN bandwidth or take the potential performance hit.

Unfortunately, iOS doesn’t support settings like this natively.

In order to accomplish this, you have to create a custom .mobileconfig file. These files are huge XML documents that you probably shouldn’t write by hand.

Save yourself a headache, use this iOS VPN autoconnect generator (props @klinquist).

Costs

I am hosting my Streisand VPN on Linode, my goto host for the past serveral years. Their lowest tier server is more than power enough to host a VPN. And they generously include 1TB of service. For US$5/mo.

The $5/mo price-point is competitive with many of the popular VPN services. Except, since you’re self-hosting, you are not limited to 1 user. You can freely hand out the streisand connection to friends and family.

Conclusion

One of the most powerful aspects of the internet and open source software is the ability to take control of everything yourself. As somehow with this skills to do this myself, I am going to start to make a concerted effort to take control of more things myself and be less dependant on untrustworthy third-parties.

Running my own VPN is just one small step.


I wrote a short follow-up post you might enjoy:

DIY Internet: More on personal VPNs

Huge Vulnerability in WordPress 4.8

Anthony Ferrara discovered a significant security vulnerability and an even more fundamental security flaw in WordPress.

The correct fix is to ditch this whole prepare mechanism (which returns a string SQL query). Do what basically everyone else does and return a statement/query object or execute the query directly. That way you can’t double-prepare a string.

It’s worth saying that this would be a major breaking change for WP. One that many other platforms have done successfully (PHPBB did this exact thing, and went from having massive SQL Injection vulnerabilities to almost none).

WordPress has made great strides in modernizing  and hardening core. I really had no idea WPDB was still in the dark ages! For shame!

Read his post for all the gory details.

Facebook Security Force

A neat little tidbit about Facebook security in this post from The Verge. Good Guy Facebook proactively scans lists of hijacked account and warns users if they appear on one of these lists.

Facebook cross references credential dumps with its entire database of user credentials, then alerts any users that match to change their passwords. By signing up for Facebook, you’ve inadvertently entered yourself into its witness protection program, of sorts. During events like the Gawker credentials leak or Playstation Network security breach last year, Facebook alerted users if their passwords were on the loose.

via The Verge