Maybe Passwords are the Future


Last updated

Most security experts seem to agree that passwords are on the way out. There is good reason for this:

  1. Users pick awful passwords, making brute force attacks easy.
  2. Users reuse passwords, making credential stuffing effective.
  3. Users can’t remember good, unique passwords for more than a few sites.
  4. Passwords can easily be phished.
  5. Passwords are exposed to the server. This makes reuse worse and offline phishing possible.

A wide variety of new approaches are vying for popularity. WebAuthn removes passwords and instead uses keys that are managed by the browser. Email “magic links” use the ability to receive email as authentication. SSO delegates the problem to another provider. However these approaches all have major downsides. Let’s take a quick look at some of these and try to squeeze them into a pass/fail score, ignoring most of the nuance.

No Memorization
This means that the user doesn’t need to remember anything. Or at worst only remember a single, relatively short, thing for all sites. (Like an SSO URL or a master password)
No Third Party
This means that only the user and the service are involved. No third party needs to be available, and no third party can impersonate the user. (The WebPKI is excluded here)
This means that all third parties can be arbitrarily selected by the user.
This means that WebPKI is not relied upon.
This means that the user can’t be tricked into giving someone else access to their account when they try to log into their account.
The user can easily log in on all of their devices that are set up with their tools and config.
The user can easily log in on a new device that doesn’t have their tools or config available.
The user also verifies the server.
The server never learns enough information to authenticate as you to someone else.
Method No Memorization No Third Party Decentralized No PKI Unphishable Syncable Transferable Mutual Leak-Proof
WebAuthn 1
Magic Link 2
SSO 3 4 3
TLS Client Certificate 5
  1. Possible but not currently available. Can be blocked by the server if desired.
  2. It is transferable if and only if you have an already-logged-in device available and the service allows following the link on a different device than the one that is trying to log in.
  3. SSO just shifts the end-user authentication to someone else, so the method that the someone-else uses you determines these features.
  4. Possible, but generally just a couple whitelisted options are available. (RIP OpenID)
  5. Possible but not widely available.

Password Managers

Personally I prefer to use passwords wherever possible. With a password manager (I use Firefox’s built in one) I know that I have strong passwords, they are synced across all of my devices, and they are only auto-filled on the correct sites. I don’t depend on any third party service (other than Firefox Sync which gracefully degrades if offline or down and has no access to my passwords) and can relatively easy copy a password into another device manually if required. It is also incredibly convenient, I don’t need to leave my browser or redirect to any other sites, I only need to click the login button because my credentials are autofilled. Let’s look at how a browser-integrated password-manager resolves most of the shortcomings of passwords:

No Memorization
The password manager remembers your password for you.
Your password manager will only fill passwords into the correct site. The times when you manually enter a password become so rare as to raise extreme suspicion, making phishing very unlikely to succeed.
Site-unique passwords means that the password the users sees is not useful to log into any other site. However the server does still see the password, so leaked logs could allow someone else to log into my account.

This leaves Mutual and a suboptimal Leak-Proof as the only downside of passwords in a password manager. What if we could make passwords more secure rather than replacing them? One solution is a Password Authenticated Key Exchange (PAKE). If added to the above table and used with a password manager all boxes would be checked!

Possible PAKE Implementation

A very simplistic approach would look like follows:

<form action=/login>
	<input type=text name=username>
	<input type=password pake>

A browser that supports the pake attribute would treat this very differently from a regular password field.

Unanswered Questions

  1. Need a solution for signup. For aPAKE algorithms this should never expose the password to the server. Maybe new a new form field? Switching behaviour on autocomplete=new-password seems wrong. Maybe pake=login vs pake=register?
  2. Need to negotiate the algorithm used with the server.
  3. Need to support upgrading passwords to better algorithms over time.
  4. Should we specify the algorithm in the HTML, or just let the browser and server negotiate the best algorithm?
  5. How do we know what the username field is? It needs to be transmitted before password validation and the rest of the form (which should probably only be transfered after authentication).
  6. What if someone manages to MITM or otherwise compromise the service? I think a lot of phishing concerns need to be considered here, but at the end of the day, the password manager loudly protesting and requiring explicit warning dismissal before filling a previously-PAKE password into a non-PAKE location should sufficiently prevent this.
  7. Does it make sense to have older browsers that don’t understand the attribute fall back to plain-text? Or would it be better to use a new element that wouldn’t work on browsers that don’t support it? I think that allowing the graceful upgrade is probably the better option.
  8. Is a JavaScript API needed? Maybe the JS could manage the credential behind an opaque reference and make an API call with it. However this means that the page before authentication can see the results so is somewhat trusted. For best security a full page reload on a new, authenticated connection should be required. What if a “client” site wants to use PAKE authentication to two backend APIs (for example a Matrix client with multi-account support)?


It seems to me that we are trying to get rid of passwords with solutions that miss some basic UX, flexibility, decentralization and security properties. I find myself often wondering if it would be better to stick with passwords as the user-visible authentication method but improve the underlying protocol to provide better security.