A place to cache linked articles (think custom and personal wayback machine)
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

index.md 5.1KB

title: It is (Past) Time for Passwordless Login url: https://medium.com/why-not/it-is-past-time-for-passwordless-login-4f468b812301 hash_url: 7ea22ac5b5

Two years ago, I wrote an essay called “Is it time for Passwordless Login?” which proposed a design pattern that would replace passwords with a one-time use login link sent to a user’s email address or phone.

In short, passwordless login replaces the username and password combination with a variation on the reset password flow already found on many existing sites. To login, a user enters their email address or phone number. A link is sent to that address that, when clicked, causes the user to be logged in. No password is ever collected or stored.

In the interim since I wrote my original essay, we’ve had a series of devastating hacks and data breaches where personal information has been accessed and stolen by cyber-criminals. Millions of passwords have been leaked onto the Internet. It now seems commonplace to hear news of “the largest data breach in history.” There are more, and more sophisticated hacking efforts going on around the world than you want to know.

It is a terrible time to own a database full of passwords.

This week, Medium launched passwordless login for their users. Slack offers passwordless login in their iOS app. Twitter offers a login-via-text tool as part of their developer tools. There is a plug-and-play Node module. This is a feasible, tested, and user-friendly way to make logging in to your app easier and more secure.

I can now say that it is past time for sites and application developers to adopt this design pattern. Why?

It is better for the user:

  • No username or password to remember — only email
  • Less typing on mobile devices
  • No risk that a future breach will expose a password

It is better for the product:

  • Account creation, login, and password reset become simpler
  • All email addresses are verified without additional steps
  • There are fewer options for users to manage

It is better for the business:

  • There are no passwords to store and protect, thus less risk of a damaging data breach
  • There are fewer features to build and maintain
  • Less support is required for helping people with password problems

Every application developer and service provider should consider going passwordless. This design pattern, particularly when used in combination with two factor authentication, server-side data encryption, and SSL will help to prevent your app from being the next to suffer an embarassing breach. And even if your app does get hacked, at least your breach will not expose user passwords that will go on to cause further breaches.