Source originale du contenu
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.