Deprecating most of our passwords

I’m happy to introduce you to a new way to do user authentication in the web. Over the years, we techies have been culprit of introducing patterns and technologies that are sound when a system is analysed in isolation, but which don’t work so well when they are adopted at scale. One classical example is the public key infrastructure where we end up trusting blindly all kind of entities around the globe. Really, our browsers trust any cert from organizations like this one (I’m not saying they are not trustworthy, just that I have no idea of who they are):

A random CA which Firefox trusts by default which I have no clue about.

A similar situation has happened with usernames and passwords. We’ve been years looking at our systems and securing them by assuming a user can provide us with some secret piece of information that only she knows. That has been an input of our system, we have taken it for granted and moved on making the rest of the system secure. We have spent great effort to store that secret so we can validate it the next time that user come to us again. Then we can go and ask: “Tell me that thing only you and me know so I can verify that you are who you are saying?”. If there is a breach in our system and someone else gets to know that piece of secret information, he can fool our system impersonating our beloved user. What it is worse, if our user has used that same secret in other systems, those are compromised as well. Last but not least, our user needs to make sure the device is not compromised, the connection is secure, no one is looking over his shoulder, etc. It is overwhelming.

Status quo

Over the years, our response has been the following (which is disheartening): “It is your problem to give me a unique piece of secret information. However, make sure it fulfils all these requirements:
>1 number
>1 lowercase letter
>1 uppercase letter
>1 middlecase letter
>1 special character
>1 not-so-special character
>1 emoji
>100 characters
etc.
etc.”
Basically, we gave up on our responsibilities and pushed all that technical debt into our users, signing off a model that doesn’t work when taking the bigger picture into account.

This mistake is now a whole ecosystem of technologies and tools on which we’ve invested significant amount of work, that maybe should have never existed: password managers, 2FA, SSO, password salting, etc (I’m aware some of them are not just about authentication but also about authorisation and they may provide very useful additional features). This has also left our users open to privacy risks (i.e.: authentication providers like Google, Facebook or GitHub can now track us as we log in to different sites and they could block you out from sites at will)

A fix has been proposed

The question is: can we fix this? Maybe. There is a new approach to web authentication that may help us providing a much better answer to our users. The key points of it are:

  • We are still asking our user to remember a secure password. But only one for all sites. The difference is huge.
  • The site needs to keep no secrets. This makes our live so much easier 🙂
  • The only password I need to remember only needs to be entered locally to unlock the identity locally. Any attacker would first need to get access to my local drive to start thinking about guessing my password. Under current model any attacker can try to guess my password against public endpoints.
  • No other entity but the site she is trying to connect to and the user herself are involved in the authentication process, which protects our user from privacy threats.
  • Use-cases like revoking a compromised key are supported by the protocol
  • Our user can now log into sites from untrusted devices (i.e.: Internet cafes, hotels, etc) without compromising his security.

This new approach has been proposed by Steve Gibson and it has been called SQRL (Secure Quick Reliable Login). I think the existing documentation will help explaining this much better than I could, please head to the project’s page to know more details: https://sqrl.grc.com . In particular: https://sqrl.grc.com/pages/what_is_sqrl/

The great community has already added multiple applications and libraries to support this new protocol:

This quick video helps getting an idea of how it works (starting at 0:54 at that is the coolest part):

The caveat

A lot of effort has been put into making SQRL as easy to use as possible and as I’ve explained in this post, you as a regular user would have so much more brain space for more interesting things than passwords. However, SQRL asks you to do this few things:

  • Remember a single secure password to unlock your identity
  • Treat your identity file as a secret file to prevent brute force attacks over it (although SQRL design makes those attacks not so effective). i.e.: don’t share it with others and try to keep the device where it lives clean from malware
  • Store the recovery text for your identity offline (do it once and put it in a safe place)
  • If you suspect your identity has been stolen from your device. Generate a new one with your rescue code and visit the sites you use as soon as possible so these sites revoke the old identity and use the new one.
  • Again, SQRL tries hard to give you mechanisms to recover from identity issues, but at the end of the day you are the only and final responsible of following the few required rules: https://sqrl.grc.com/pages/three_golden_rules/

How do I use it?

When it comes to how I use it, I don’t feel comfortable having to unlock the SQRL identity on my laptop when I need to use it and I feel mobile OSs have gone through a greater focus on app isolation and secrets management. So overall I feel that using the SQRL mobile app brings the best experience to me (please, I’m eager to know your views on this in the comments):

  • My phone is always with me if I need to authenticate anywhere
  • I have my identity stored in very few places
  • I enter my identity password on few devices
  • Having my identity stored in the browser (i.e.: using browser’s plug-in) seems like a greater risk for me

By the way, this site already supports SQRL 🙂 . Thus, you are very welcome to post a comment authenticating with SQRL 😉

Again, the official forums are a great source of information: https://sqrl.grc.com/pages/whatif/

9 thoughts on “Deprecating most of our passwords

  1. So happy to see that SQRL is now live! I’ve been waiting for years and am really stoked. Trying to spread the word to my social circle.

  2. Just SQRL’d into your site.
    Magical!
    Your description of SQRL and the problem that is solves is well done!

  3. Just in the process of setting up a full revamp of my personal website that hasn’t been updated in a decade or so. My main concern is the ability to use SQRL, so that limits my choices a bit for turnkey content managers. I may never log in here again (although I do see a couple of interesting articles) but this was the first WordPress site I found that demonstrated the correct operation of SQRL. Thanks.

Leave a Reply

Only people in my network can comment.