Would You Implement Passwordless Login?

How many passwords do you use for online accounts? I have 250. That’s a conservative estimate and doesn’t include a plethora of hosting, database and SSH passwords.

Despite using management tools such as KeePass, it’s difficult to use different passwords for every site — and I certainly don’t change them as often as I should. Even then, I forget what I’ve used on specific sites. Logging in is often a matter of clicking “forgotten password”, hitting an email link, entering a new password and finally gaining access.

The average user has a couple of easily-remembered passwords for every account. There’s no guarantee every one of those sites has implemented good security measures. Perhaps passwords are stored in plain text or accessible to their staff, developers, database administrators or those working at their hosting company. Could your banking account be accessed just because you used the same credentials at dodgysite.com?

We’re using the same ID and password mechanisms we implemented at dawn of the web. But a password backlash has begun. Passwordless logins have been proposed by developers such as Justin Balthrop and implementations have arrived, e.g. passwordless.net for Node.js. The main argument: passwords are obsolete because we all have secure email and mobile SMS accounts.

Passwordless login uses the following process:

1. The user accesses a website and enters their email address (or mobile number).
2. A token (cookie) is sent to the device. A unique authentication code is generated and stored on the server then sent within a link to the user by email (or SMS).
3. The user has a limited time to click that link — perhaps ten minutes. When clicked, the existing token and authentication code are verified to ensure the same user is accessing. The user is then logged on and a session is started using a long-term token.
4. The user does not need to repeat the process unless they log out, switch browser, do not access the system for a specific duration or want to use another device.

In essence, it’s a similar process to resetting your password — which you would possibly have had to do anyway. The benefits include:

• There’s no need for clever hardware or biometrics — the user just needs an email address or SMS number. That’s far more likely than having a Google, Twitter or Facebook account which can thwart those using OAuth providers.
• You need never manage passwords again. There’s nothing for the user to invent, reuse, note down or reset. Support staff are freed from daily grind of account management duties.
• The user requires a valid email to log in so the usual registration and email validation shenanigans are avoided.
• No password is ever stored or sent. It cannot be guessed or hacked. Someone could grab your database and intercept HTTP traffic or email messages — they’d still have difficulty logging in.
• There’s less code to deploy. Login forms have one field and security management is minimal.

Going passwordless is not a magic solution appropriate to every application. System developers will need to consider a number of issues…

User Expectations
I’m yet to use a passwordless system in the wild. While it shouldn’t be a difficult experience, few users will expect it. That could lead to additional support calls in the early days of deployment.

Logging on Takes Longer
Despite time savings in password management, passwordless login could be annoying. It’s impossible to save credentials in the browser so you can never login automatically. Often-used applications such as social networks and large online stores would avoid going passwordless.

It’s Not Suited to All Applications
Passwordless login would be difficult to implement on a webmail client! In addition, you wouldn’t want your bank handing password security to a third-party.

Email Hacking
If someone hacks your email account they have gain access to all your passwordless systems. It would fairly easy to discover which systems you’re using just by examining the deleted items folder. That said, if someone hacks your email account they can also reset your password at many sites using standard authentication.

However, a large number of applications could benefit from a passwordless approach. You could certainly consider it if your system is used fairly infrequently and has minimal security implications, e.g. forums, support ticketing, analytics, monitoring, reporting systems etc.

Passwordless isn’t for everyone. Implementation libraries are scarce and some companies would be nervous about becoming an early adopter. But I like the idea and investigating the viability for a system I’m working on. I’ll let you know how it turns out.

Would you go passwordless?