Passwords are Obsolete

And they make Heartbleed a thousand times worse


I have 268 passwords on 268 different websites. At least that’s what my password manager says. I actually stopped saving new passwords a while back, so the real number of passwords I should change now that Heartbleed has been revealed is even higher than that. How many of those passwords do you think I’m going to change? It took me 10 minutes just to find the change password form for my bank! What about the average computer user who uses the same password for every website and doesn’t understand the details of the exploit? How many passwords will they change?

Not very many.

Everybody knows that most passwords will remain unchanged. Yet our collective response to Heartbleed has been to patch our servers and email users asking them to do something we know most of them won’t do.

Here’s what our response should have been:

ALTER TABLE users DROP COLUMN password;

It turns out that passwords are obsolete, and they have been for a long time. Like the occasional pay phone you find in the back of a run-down restaurant, passwords have been unnecessary for years. The difference is that everyone laughs and reminisces when they see a pay phone, but nobody does that when they see a password field. But they should.

There are two separate technologies that have made passwords obsolete, and they aren’t the ones you would think. You may have guessed fingerprint scanners. Or voice recognition. Or maybe iris scanners. Nope. The technologies that made passwords obsolete have nothing to do with biometrics. And they have been mainstream for much longer.

Passwords are obsolete because of email and SMS. Specifically, the ability to send an email or SMS to users reliably and quickly. In theory, we’ve had that ability for a long time. And with the rise of services like Twilio for SMS and Mandrill for emails, it’s incredibly easy.

The basic idea is that instead of using a password to authenticate each user, a temporary secret code is sent to them over a secure channel. Email or SMS is that (mostly) secure channel. It’s almost as if the backend server makes up a temporary, one-use password each time a user wants to log in and whispers it in their ear.

The interesting thing is that we already use exactly this flow for password reset emails. This is why I previously recommended taking advantage of this so you could stop remembering your passwords.

My argument was mostly from the perspective of convenience though. I assume you’re using a different password for every website. There’s no way you will remember all of those passwords, and it is pretty inconvenient to have to put every single one of them into a password manager. Especially on a mobile device. So instead, you make up random passwords, immediately forget them, and use the password reset flow next time you need to log in.

But the recent Heartbleed bug highlights the fact that hacking password reset flows for convenience is not good enough. We need to convince websites to stop using passwords altogether.


Here is how the passwordless service could have responded to Heartbleed:

Hey there, user.
We wanted you to know that Heartbleed affected our servers and that we updated our version of OpenSSL to fix the bug. We really care about security, so we immediately invalidated the tokens of all our users when we heard about the vulnerability. There’s nothing you need to do except re-authenticate using email or SMS next time you use our service. This is exactly the flow you use every time you log in, so you should already be familiar with it.
Please email us if you have any questions.

Instead, we’re getting a bunch of emails telling us we need to spend the next week changing all of our passwords. We should respond to each of these well-intentioned emails telling them that they shouldn’t be using passwords at all. Something like this:

Hey there, developer.
Thank you for taking the time to email me about Heartbleed. I’m glad that you have updated your version of OpenSSL, but it isn’t really practical to expect everybody to change their password on every site on the entire internet. Instead, websites like yours should be taking this opportunity to get rid of passwords altogether. There’s this really cool thing called passwordless authentication that you should look into if you care about security. If you want more information, go to http://passwordless.org.
Thanks!

Passwordless Authentication

Here’s how passwordless authentication works in more detail:

  1. Instead of asking users for a password when they try to log in to your app or website, just ask them for their username (or email or mobile phone number).
  2. Create a temporary authorization code on the backend server and store it in your database.
  3. Send the user an email or SMS with a link that contains the code.
  4. The user clicks the link which opens your app or website and sends the authorization code to your server.
  5. On your backend server, verify that the code is valid and exchange it for a long-lived token, which is stored in your database and sent back to be stored on the client device as well.
  6. The user is now logged in, and doesn’t have to repeat this process again until their token expires or they want to authenticate on a new device.

If every site on the internet did authentication this way, the response to Heartbleed could have been swift and decisive. Instead, we’re faced with the fact that millions of stolen passwords will never be changed.

All the Details

Of course, there are a lot more details to an actual implementation.

How long should the secret code be? What random number generator should we use to generate it? How can we protect against brute force attacks and other ways nefarious characters may try to abuse the system? How convenient will this system be for users in practice? Don’t users still need a password for their email accounts? Doesn’t this make it even more essential that everyone use a pin or password to protect their phone?

I plan to write another post discussing these details. And I may open source the implementation of passwordless authentication I wrote for my own startup. But I promise the answers to these questions that we come up with as a community will be way more secure in practice than just asking users to choose a good, unique password and change it regularly.


Epilogue

January 2015 — I still plan on writing a follow up post, but I’ve been busy working on my startup. Swim is a consumer, mobile, social messaging app. Of course, Swim doesn’t use passwords, and it has worked out great. The answer to the question “How convenient will this system be for users in practice?” is a resounding, “very convenient.” I’ve also seen more and more apps go passwordless since this post was written, which is a very good thing.

If you’d like to see the passwordless start flow in practice, check out our iPhone App (Android coming soon). I’d love to hear your feedback.