Going Passwordless for a More Secure and Welcoming Future

If you're a product owner you may be a little confused by this concept. After all, we've been using passwords to protect our users for as long as apps have been around. How could you possibly verify someone's identity without a password? There are a few methods to do this:

Magic Login Link Emails: These emails contain a link to your application. The link includes a token that is valid for a short amount of time and will automatically sign the user in when visited. After the link has been used once it is marked as used so it cannot be used again. This mechanism relies on our knowledge of the user's email address. Effectively we're using their email address as their identification.

SMS One Time Pin Codes: If we've collected the user's phone number we can send them an SMS with a short code, typically 6 numbers. If you're building native apps, there are mechanisms you can use to intercept these codes from SMS messages and auto-fill the login form to create a really nice user experience. 

Email One Time Pin Codes: The same as above but for email. In my experience this is slightly less preferable to SMS codes as the integrations are not available to auto-fill forms for the user. SMS messages also show the codes in the notification when the user receives the SMS whereas emails typically only show the sender and the subject.

Removing passwords from your database greatly reduces the risk of your service being attacked. Users will often reuse passwords across all of their apps. Even if your security is strong, if another service has their database leaked you could also be leaving your users vulnerable.

Users are also notoriously bad at choosing strong passwords. Large numbers of users will use very weak passwords. It was recently revealed that President Trump's twitter password was MAGA2020!. The "hacker" didn't need to work very hard to attack the President of the United States of America's account. You should assume that your users are just as incompetent at setting passwords. A lot of users see passwords as a necessary inconvenience rather than a protection.

Passwords increase costs in both development and DevOps as you need to continuously ensure that your service and infrastructure are secure. Switching to passwordless reduces your security exposure. Phishing also becomes less of an issue as there's nothing to phish for.

Sharing passwords is fairly commonplace too, which weakens user security and also often bypasses your pricing structures. With passwordless authentication you often make it so difficult to share accounts that people won't bother. 

Password authentication also has multiple attack vectors that don't require users to be complacent. For example, brute force and password spraying attacks are possible without knowing anything about a user. Without a password to crack there's no opportunity here for attacks.

Sign up flows can be streamlined when no password is required. Users often find setting passwords tiresome. Most professionals use password managers to set their passwords for them but many non-technical web users don't. This can cause unnecessary stress or worse, weak passwords. While we can add restrictions on the types of passwords that can be used, having no password is no doubt even simpler from the users perspective.

Having no passwords means nobody needs to ever reset a password. We can completely remove this functionality from our apps which reduces development time and costs.

Young internet users are using email less and less. Giving users the opportunity to sign up with a phone number instead gives you a greater opportunity to capture this demographic. 

While there are many benefits, there are still challenges. For example, if a user loses access to their email or phone number, you probably want to give them some mechanism to reset their account. This challenge is present in password-based authentication - it's just slightly different as they can still sign in to update their email or phone number as long as they haven't lost their password too. Often applications will allow users to set both their email and phone number to reduce the risk of losing access.