An argument for passwordless

A warning upfront: this is not a “passwords are dead pls don’t use” article, but my attempt at convincing you to consider alternatives to password authentication. I also include a primer on the different passwordless authentication techniques you might want to use.

Aren’t passwords just awesome?

The concept behind passwords is quite simple. You present the user with a “password” field and imply the instruction:

“Please come up with a secret phrase that you’ll have to remember and protect indefinitely.”

…then expect the user to take their time iterating over phrases in their head, finding one that appears to be unpredictable yet memorable, and maintaining it in their mind-palace of well-crafted passwords, ready for use! Sounds great huh? No. That’s not even close to what actually happens. You see, most of your users go down the path of least resistance. But you already knew that! So what have you done about it? Let’s see…

Created a new breed of software with the sole gone of managing passwords

Hashed and salted all passwords

Added multi-factor authentication

Allowed password resets via email

Added security questions (didn’t work out did it!)

Created databases of previously compromised passwords to check against~

Wow. Talk about keeping it simple! At some point all these measures go against the grain as we move towards something reminiscent of the XY problem. Instead of trying to find a solution to the real problem, we’re desperately trying to make passwords work. Trying to patch together one of the solutions to the problem instead of considering the alternatives. We’re reaching a point where using a password to secure your next hit web app might just be impractical.

Don’t get me wrong - passwords can be great - and in some cases might be the only option. If you’re writing authentication code for a nuclear control system, the Windows login screen, the world’s largest bank, or even an email server, using a passwordful system with convoluted requirements might be appropriate.

But I’m part of the 99%!

If you’re creating a social network where the average user almost never has to login again, you might want to consider alternatives. Storing passwords and securing them at that scale simply becomes a liability. If the user’s password is “strong”, then there’s a very good chance they won’t remember it. Instead, most of your users will resort to password reset on the rare occasion where they need to login - rendering the password useless. This is even worse than it sounds,considering the great lengths you had to go through to allow password authentication in the first place.

Which brings me to my next point: password reset. Such a great feature it is. One where you get to bypass all those intricately crafted password security mechanisms with the click of button! For sites that offer password reset via email (which is most sites!), you should seriously reconsider using passwords for authentication. By allowing password resets, your users now have 2 passwords each. Even more worrying, your users think there’s only the one password - misleading them into an illusion of better security (don’t expect your users to go on and research what kind of password reset mechanism your site has). On the other hand, passwordless systems that rely on emailing “magic codes” usually make the underlying security procedures much clearer to your users.

Let me think about this…

So the next time you decide to use a passwordful authentication system, ask yourself:

How often will users have to recall the password? Is it often enough that it makes sense to use a password or is logging-in a rare occasion?

Is asking the user to come up with yet another unique password going to be worth their time? That is, are they likely to actually do it?

Are users able to simply reset the password via email? Is it clear to your users what the security implications of having their email compromised are?

Is the majority of your audience security-aware enough to properly use a password manager?

Is maintaining/protecting a database of password hashes worth the risk? Are you willing to put in the extra effort?

And after giving this some consideration, you’ll realize that you really don’t need passwords most of the time.
Passwordless systems are much easier to maintain and implement (they’re are a subset of passwordful systems in terms of implementation). An example would be using magic links or codes to authenticate your users. At a higher level, this is really just a glorified email password reset feature. But it works. Off the top of my head, some benefits include:

Frees you from having to handle user credentials in any way

Simpler to implement, leaving much less room for vulnerabilities and alleviating the need for convoluted logic (ie. this won’t happen)

Removes the need to guide/educate the user into creating “strong” passwords or how to protect them (I can finally sleep at night~)

Provides a much better UX for your users (look at that, no password field to fill out!)

All user emails are verified by default (something you should be doing regardless of your authentication scheme)

Clearly communicates all associated security implications to the user

Results in a smaller attack surface (given passwordless is a subset of passwordful)

Passwords from your company won’t appear in the next hot data breach of 2018, hurrah!

I’m sold.

If you’re convinced, here are a few good options for passwordless authentication - noting that they are stack-agnostic:

Cierge: a passwordless user authentication and management server built on OpenID Connect*

Portier: simple passwordless authentication system that’s the successor to Persona

PwdLess: a lightweight passwordless API you can get started using in 5 minutes*

Cierge’s GitHub README also has a good summary of the various pitfalls associated with email-based passwordless authentication and the measures taken to avoid them.

Conclusion

I hope I’ve convinced you that passwords are not the be-all and end-all of user authentication. Always assess the situation and carefully choose an authentication scheme that fits your requirements. I’m open to further discussion - if you think I’ve missed something I’d be happy to edit this article to include it.