One place where both businesses and consumers agree is login safety. For consumers, it's important that they trust the login of their apps and websites because they are handing over sensitive, personal information. For businesses, keeping that information safe is of the utmost importance — nobody wants to send out a notification that their system has been breeched.
So when a new way to log in comes along, it's only natural that we respond with skepticism — is this really safe? — because we know how important a secure sign on is. In the case of passwordless authentication, that reaction is particularly strong, because we have had it drilled into our heads that passwords are the ultimate source of protection for your account.
Although that skepticism is healthy and helps us find the best, most secure ways to log in, Auth0 is here to clear things up. Not only is passwordless authentication safe to use, it might even be safer than a traditional username + password login.
What is passwordless authentication?
Passworldess authentication is a way to configure your login, well, without a password. For example, a user might register their email and then receive a single-use passcode for each sign on. One common example of this is Slack's magic links. Put in your email, hit “Send Magic Link,” and you can log into Slack from your email inbox with no password.
While it is not as popular as other forms of login yet, it is sustaining rapid growth.
In fact, by our estimates, it could overtake passwords as the primary form of login within the next ten years.
But magic links are just the tip of the passwordless iceberg. There are several different ways you can configure your passwordless login. Here's a quick overview:
Magic link through email: In this scenario, a user is asked for their email. Once they've given it, the IAM (in this chart, Auth0) facilitates the creation of a token that allows the user to log in through a link sent to their email.
Code through email: This works similarly to a magic link, but instead of a token, a one-time code is generated. This starts a session when a user retrieves the code from their email and puts it into the app or website.
Code through SMS: This is the same process as code through email, but the one-time code is sent through SMS instead. Auth0 protects SMS messages with Twilio to keep everything secure.
Auth0 Guardian: Instead of putting in a password, with Auth0 Guardian you can approve or deny login requests on a second device paired with your account via the Guardian app (compatible with smartphone or smartwatch). When there's a login attempt, you get a push notification that allows you to log in with the swipe of a finger.
How does the safety of passwordless authentication compare to other logins?
The technical side of both passwordless and username + password authentication has many considerations. It's up to the company to make sure that they are storing customer information correctly and to protect it from hacks. There are best practices for each method, and, if done correctly, there isn't a runaway winner.
Here's a brief rundown of how things stack up on the technical side of things:
- Numerical Passcode: Apple cites a 1-in-10,000 chance of a numerical passcode being guessed (or generated).
- Passwords and passphrases: If a password or passphrase is unique and complex, it can be a perfectly adequate form of security.
- Login codes and magic links: Since each time a login code or link is used it is generated, there isn't the same type of risk for a security risk via brute force generation. When a login code or link is sent, an IAM should ensure that the channel is secure. If the code or link is not used within a certain time frame, login access will expire, to guard against malicious use.
- SMS risks: Codes sent via SMS may carry more risk factors because of phone networks' vulnerabilities, but otherwise operate similarly to other login codes and magic links.
- Guardian: App authenticators like Auth0's Guardian also use token generators, but have the benefit of not relying on SMS messaging.
All good IAM systems like Auth0 will have safety nets in place to mitigate the risks of brute force attacks, recognize malicious login attempts, and alert users of potential threats. They will also have advanced encryptions to keep data safe and will do their utmost to protect data at every step of the process.
Where things really get interesting is how user behavior affects the safety of login systems.
Unfortunately, even the best-laid plans can be rendered insecure when people use unsafe login practices. Let's look at how user behavior can compromise the safety of authentication, and especially how passwordless authentication deals with this.
Username + Password
By now, it's pretty clear: we reuse the same passwords over, and over, and over. The Telegraph reported that “the data shows that at least some people are still failing to heed even the most basic security principles about secure codes.” When you look at the best ways to keep your personal information secure, it's no wonder why: it takes time and attention to ensure security with a password.
With an average of 130 accounts registered to one email in the US, it's not surprising that 73% of users have duplicate passwords. To remember 130 different passwords would be extremely difficult for anyone — and probably send password retrieval requests through the roof.
These bad habits can make it hard to protect your users, no matter how good your system is. When one password is used across multiple accounts, that's a huge risk that is completely out of your hands.
Eliminating The Password
Passwordless authentication, by its nature, eliminates the problem of using an unsafe password. This means that one of the biggest user errors is taken out of your login.
One of the biggest skepticisms around passwordless authentication is the idea that using a channel like email to send a code or link can be unsafe because it can be compromised. This is a legitimate concern, but a compromised email account could also be used to “reset” a password, and therefore this concern presents no additional risk for the passwordless method over username + password login.
Passwordless authentication can also have the added benefit of two devices required for login. If you are authenticating with Auth0 Guardian, for example, you would need the device paired with the account in order to access that account, even if you knew the username. Of course, it is possible for devices to be stolen, but it makes malicious logins more difficult
Requiring two devices for login is part of multi-factor, physical authentication, which is the most secure login option. Each individual method has a single point of failure, and multi-factor authentication helps reduce impact of a single system's flaws.
For login, passwordless is the future
Although this has not been an exhaustive exploration into all of the safety considerations relevant to the username + password and passwordless methods, it's clear that the technical foundations of passwordless authentication are safe and robust.
Although username + password is currently the most familiar login method, it is by no means the gold standard. Yes, much of this rests on the way that users behave. Unfortunately, humans simply aren't built to remember and use different secure passwords for all of our 130 accounts.
Passwordless authentication, then, is becoming an increasingly relevant option for login. Users are connected to more devices and have more accounts than ever, which means that the passwordless approach is only growing more convenient for users. Sometimes it's also the case that you have to save the user from themselves — and for that, passwordless is a clear winner.
About the author
Martin Gontovnikas
Former SVP of Marketing and Growth at Auth0
Gonto’s analytical thinking is a huge driver of his data-driven approach to marketing strategy and experimental design. He is based in the Bay area, and in his spare time, can be found eating gourmet food at the best new restaurants, visiting every local brewery he can find, or traveling the globe in search of new experiences.View profile