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?

--ADVERTISEMENT--

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?

Replies

  1. Really? Why?

    I like it. :) I may offer this as an option to users on the next site I build. You're right that it's the exact same "Forgot my password" process we already use, so why not make it the normal way to log in.

  2. In theory, a great idea.

    In practice, I could see an approach such as this being open to abuse and would require a few additional steps such as regional locking, maximum attempts per hour/day/month, etc.

    The potential for crashing the service, or racking up huge SMS bills would be quite high, and similar risks with email spamming. (A malicious person/group abusing the login page)

  3. zackw says:

    Steve Gibson's SQRL idea is perhaps a much better system to relive the "annoying" part of logging in this way.

    https://www.grc.com/sqrl/sqrl.htm

    I would not want passwordless login in the way mentioned in this article. Using LastPass is plenty easy and I can use it on all my own systems, or log in to their website to retrieve passwords if on some other system.

  4. I agree with @zackw. SQRL is the only one I'd rely on because it's the only one I've seen not dependent on a 3rd party. I hope it takes off in a big way. For now, I'll keep using 1Password to generate long, very random passwords unique to every site.

  5. ceeb says:

    Really? Why?

    Because opening KeePass (or similar) is still more difficult than using the same password on every site!

19 more replies