Pre-RFC: the password API

We need to talk about passwords.

Shortly after the Heartbleed vulnerability was announced, I found myself completely inundated with notices, requests, and demands to reset my passwords. This went on for days, then weeks, with dozens of services eventually getting around to discovering that their users may have been vulnerable to SSL attacks, and sending out alerts prompting a password reset.

And those were the services which, as far as I know, probably weren’t even breached. Contrast that with the numerous username / password pairs I’ve actually had exposed and out there on the open internet, extracted from the databases of companies large and small, seemingly technically adept and, well, not.

I have a feeling I’m not alone in these experiences. It sucks. But somehow we’ve all bizarrely learned to accept it as part of life on the internet.

Is there any escape? I mean, even President Obama has determined that we’re more likely to pass legislation (compelling companies to follow specific security breach guidelines) than to actually count on anything to meaningfully improve.

The fact is, we’ll probably never be free of an internet without security breaches. But the least we can do is make some improvements with how the all handle the holiest of holy bits of data we store in the cloud: passwords.

Passwords suck.

We all hate passwords. And for anyone who builds stuff on the internet, each year’s top leaked passwords lists is as hilarious as it is depressing. Why are passwords even still used anymore?

Well, for one, passwords are in the pantheon of elegant, elemental concepts that have laid the groundwork for the technologies and services we all use today. Like some of those early ideas still in use, passwords haven’t aged very well over the years (I’m looking at you too, email), but they work. Until they don’t.

Today, at best passwords serve as an untrustworthy nuisance that, by their very design, encourage undesirable behavior by end-users. No human can remember a unique, challenging password to every site and service we use, so most people resort to easy to guess — even easy to type—passwords that are often repeated across services, and rarely changed.

The flip side of this is that for anyone who runs a site, app, or service that utilizes some form of username + password pair, passwords are a huge liability. No one really wants to be the keeper of a database of user credentials. Not only does that make you a target, but it means you’re responsible for all the eventual damage following a breach caused by your users’ insistence to use easily guessable passwords.

Authentication alternatives exist, like Facebook Login, but not every organization is at liberty (or wants) to to deploy these kinds of tools. Even if you assume Facebook can’t be hacked, what if their Facebook identity gets compromised because it uses a username and password shared with some other service that was hacked?

If you dig far enough down, eventually every user is logging into something, somewhere, with a username and password.¹ And those credentials are likely shared with something else even less secure than Facebook, Twitter, Google, etc.

Like so many early concepts and technologies, passwords are woven into the fabric of the internet. If it isn’t already clear by now, they aren’t going to vanish any time soon.

Reflection

So, in a post-NSA, post-Heartbleed, post-every-service-has-already-been-or-will-be-hacked world, what can we do to protect ourselves and our users (for those of us lucky enough to have them)?

Well, let’s consider the most important three things about using passwords today:

1. One should assume any service making use of passwords will be hacked. Go ahead and assume the sites and services you use will be subject to an ongoing series of breaches, not all of which we’ll hear or know about. If you make that assumption, which I think is pretty fair to make, then the only safe thing one can conclude about passwords is that they are or will eventually be compromised.
2. The only good passwords are unique, complex strings. Ideally the longer and more randomized the better. They’re not only essentially impossible to guess (or crack via rainbow tables, etc., especially when your service is kind enough to salt them), but in the event a password / hash database does become compromised, exposed passwords can’t be pattern-matched in the future based on publicly available knowledge about you. In other words, uniqueness and randomization helps ensure near complete isolation of a single account in the event of a breach (with certain exceptions).
3. Given points 1 and 2, the best (and really only) defense against any eventual compromise of your auth credentials is to employ frequently changing, randomized passwords (wherever passwords are needed).

Good luck with that.

As of this morning, I personally have about 800 internet accounts with various forms of user/password credentials in my 1Password vault. As time goes on, the odds of one of those 800 services being hacked in any given month likely approaches 1. I cross my fingers that I’ll hear about it before any bad guys do.

If you spend a lot of time online, you might want to consider hiring an assistant to help you change your password on a monthly basis.

And then there are the other 98% of people online who don’t even employ any formal password management routines or software. For those people, a breach could be catastrophic — and that’s assuming they even find out about it (which, again, you really shouldn’t assume).

Most people think of passwords as a thing you have to memorize, but in reality it’s quite the opposite: no one should actually know all their passwords. Just whatever is absolutely necessary to authenticate the smallest number of tools or services necessary, such as a password manager.

Let me say that again.

Your beautiful, imperfect brain should only need to know one password. (Maybe two.)

I know. That’s counterintuitive to the way most people think about things today. But that’s because our passwords should change themselves, and they don’t. Yet.

A solution

If we agree and accept the basic state of affairs with regards to passwords, and agree that they aren’t going away any time soon, the internet needs to rally around a few basic countermeasures to protect ourselves (and our users).

The solutions are totally debatable, but I believe the most people would be best protected by using a combination of password-free authentication systems (like Facebook Login, or example), client-side password management tools (like 1Password), and perhaps most importantly, an invisible, standard password API.³

A starting point for discussion:

1. Encourage password-free authentication. The fewer passwords in existence, the better. Our online identities are only as strong as the weakest service we use that stores passwords — and I’d be willing to bet we all use at least one service that has unpatched vulnerabilities and that stores our passwords in plaintext. If you build stuff and don’t know the difference between MD5, SHA, and bcrypt, please just use Facebook or Twitter Login. User-facing products should strongly encourage people to take a password-free path and authenticate via existing systems and protocols.
2. There exists a need to develop an open, standardized password API for programmatically invalidating, generating, and storing passwords from one or more trusted, secured sources. This standard would, ideally, be built directly into browsers (the most common means of web-based password storage) and tools like 1Password and Lastpass.
3. Ideally, password API clients should act on the behalf of its users and frequently auto-expire passwords from the client side. Users should not need to be responsible for changing their own passwords.
4. Additionally, one might also opt to invalidate and create and send new passwords upon every user requested login action. (This doesn’t necessarily make anything safer, per se, but it might help increase password cycling, thus minimizing potential damage in the event of a breach.)
5. Should a service be compromised, sessions should be automatically invalidated and password API-enabled clients be able to detect an alert status on next check-in. Reset requests may also be sent to clients (and users, presumably via email).

Ideal real world results:

1. Fewer sites and services would make use of passwords of any kind, period.
2. Most users would no longer have any duplicated passwords, because most users would no longer even know every password for each individual service.
3. Most users would have no passwords in active circulation on any 3rd party service for longer than a few days.
4. The risk of 0-day vulnerabilities and most breaches therefore become increasingly trivial. Even stealth, ongoing breaches of services become less damaging due to the fact that users would be less likely to be using any common or duplicated passwords, provided the entire password process was automatically managed for them.

Think about what a password is for a moment. It’s a way to prove to a machine that you are really you, right? It’s already possible to prove that you’re really you without even having to know all your passwords. So why are we even bothering to deal with these things?

Is a password API this an achievable future? Hard to say. Many of the sites and services in use today that rely solely on username / password pairs are legacy systems, with cruft and red tape that could take years to deal with.

Still, remember that every strong, frequently changed password is one less attack vector to worry about later. Moving to a common password API doesn’t have to achieve 100% saturation in order to make a meaningful improvement. In today’s internet, every little bit of increased security counts.

Would this solution solve every problem associated with passwords? No, definitely not. But it might help conquer a few of the most pertinent issues associated with the human element (remembering a secret) of a very old technical problem (authentication).

We know people often tend to take the path of least resistance, even if it means reduced security. The reality is we can pretty easily build a set of standards and tools that can increase the robustness of the password security model while also making safer passwords drastically easier to use.

Let’s let machines do what they do best: do work on our behalf. In this case, that work can be to keep us a little more secure.

Feedback me

This whole password API concept is intended to stand apart from existing, excellent standards like Oauth2 or OpenID, and deal with the existing realities of the username / password pairs that aren’t going away completely any time soon (as much as I wish they would).

That said, I’m not a security expert. Which is why I’d love your thoughts and feedback.

Please hit me up on Twitter! I’d love to hear what you think, and whether we should pursue this concept at Alpha.

¹ And that’s ok! This post isn’t about spreading password FUD.
² Unfortunately, random passwords also kind of suck to use on any device you can’t copy/paste into, but that’s another topic for another day.
³ I should say up front, I’m not presently working on this problem at Alpha, but if there’s sufficient interest, I may.