Why Passwordless Authentication Works

In December 2014, I published Would You Implement Passwordless Login? It expanded on articles such as Justin Balthrop’s Passwords are Obsolete and Ben Brown’s Is it time for passwordless login? The Passwordless project for Node.js has inspired others, including options for PHP and Ruby. I mentioned considering passwordless authentication for a client project. I’m pleased to say it’s been operating for several months and has been a revelation. More about that shortly — but first, let’s recap …

What is Passwordless Authentication?

We’re using the same authentication methods devised at the dawn of the web. Unfortunately, passwords are increasingly broken:

• People rarely create strong passwords. Surveys report one in ten accounts use something from the top twenty most popular passwords. “123456” is used by more than 4% accounts; “password” remains the second most-used.
• People use the same terrible password on multiple sites. If you happen to crack someone’s Facebook login, you can probably access their PayPal account. Your single password is only as good as the security of the weakest system you use.
• Corporation hacks are increasingly common and attract mainstream media interest. It’s an easy route to make a name for yourself, extract revenge or indulge in blackmail. Few companies are prepared for acts of cyber-terrorism and, despite the usual claims of “sustained sophisticated attacks”, many breaches are simple SQL injections caused by poor development techniques.
• From a coding perspective, authentication is tedious and mistakes are made. Checking credentials is the start of your problems: you need to ensure there are no cracks in security, hash strings using strong (and slow) algorithms, allow users to reset forgotten passwords and answer support calls from confused users who are seemingly unable to remember or type a short string correctly.
• Alternative solutions such as biometrics or OAuth depend on hardware or suitable social media accounts. Few sites implement it well, and still need to revert back to email/password methods for some users.

The premise of passwordless authentication is that passwords are unnecessary when the majority of users have secure personal messaging accounts such as email and SMS. Applications can leverage these systems:

1. To log in, the user visits a site and enters an ID such as an email address.
2. They are sent a message with a link; they click it and are logged in.

In other words, the application creates a random, one-time password, and whispers it to the user whenever they need to access. It’s a similar process to resetting your password — which many users do every login anyway! Email is an obvious choice, but any other messaging service can be used — such as SMS, Slack, Skype, instant messaging or even Twitter direct messages. Multiple options could be offered if you don’t want to rely on a single system. It’s a little more complex behind the scenes to ensure only one person can use the login link. The general process is as follows:

1. When entered, the server verifies an account exists for the email address.
2. The server creates two tokens, such as 24-character hex GUIDs, and associates both with this login attempt. The first token is sent back to the login device — typically as a browser cookie. The second token is encoded in a link sent to the user by email.
3. When the link is clicked, the server will receive both tokens and verify them against a single login attempt. Optionally, it can make further checks to ensure the link has been clicked within a few minutes and the IP address and browser user-agent string have not changed.
4. If everything verifies, a real session is started and the user is logged in. If anything fails, all associated tokens can be invalidated; it’s impossible to use them again.

The benefits of passwordless authentication:

• It’s considerably simpler for users. There are no passwords to create or store. You don’t need a social media account or third-party software other than access to your messaging system. It’s impossible to register without valid credentials.
• It’s more secure. No passwords are stored and there’s nothing to hack or guess. Even if someone intercepts a message, they’d only have one of the two tokens and couldn’t log in.
• It’s cost-effective. There’s less code to develop and deploy. Login code is mostly handled by another service with robust security. Your support team is freed from endless password problems.

Where can Passwordless Authentication be Used?

Logging in takes a little longer — but so does using a password manager! Passwordless authentication can be offered on applications which have reasonably long session timeout periods, or where users only need infrequent access. Shopping sites, social networks, forums, ticketing and content management systems are good use cases. It would be strange to use passwordless authentication on a messaging system, since you’d require another to log in! Nor would you want your bank depending solely on AOL for their security, although secondary identification processes could supplement it. Passwordless can be considered if you’re creating a new application. However, updating an existing application with many users who currently have passwords is more problematic. I suggest running passwordless authentication in parallel rather than switching to a new login process overnight. Offer it as a choice — especially to users who reset their password — and assess uptake after a few months to determine whether it’s viable.

Real World Test

I implemented passwordless authentication on a new application used by a client for several hundred internal personnel and external customers. Around half the userbase have good IT skills and access daily, so their sessions rarely expire. The other half are mostly managers who log in once or twice per month — many forgetting or mistyping passwords. The biggest issue: clients must be convinced. “Passwordless” sounds insecure, and few people will have seen it used elsewhere. I was lucky: the client had a single technically-savvy project manager who understood the concept. Even then, I agreed to add passwords if anything failed. It was plain sailing from that point onward. For technical reasons, I had to integrate my own implementation rather than rely on a third-party library. It took less than one day, and there was no need for the usual password management, hashing and resetting nonsense which we normally develop and test. The biggest bonus: users understand passwordless authentication. The process is simple, but it’s best to provide simple instructions at all stages. For example:

• A login link has been emailed to you. Please check your spam folder if it does not arrive.
• Please click this link to log in … You have 10 minutes to open this link in the same browser.

No one was confused. No one struggled. No one praised the system but no one complained either; people accepted the process and it didn’t get in their way. The number of password-related login issues reduced from three or four per week to zero.

Conclusion

I couldn’t claim passwordless authentication works everywhere, but the experience has been overwhelmingly positive. I’m a convert. All my applications will be passwordless from now on. Some clients may not be happy — but I’ll just pop a dummy password box on their login form and ignore it! Have you implemented passwordless authentication? Was it a good or bad experience?

Frequently Asked Questions (FAQs) on Passwordless Authentication