Out with ‘12345’ – Discover Passwordless Authentication Methods

Passwords are inherently flawed, both in terms of security and user experience. We present a range of passwordless authentication methods you can use to make your app secure and user-friendly. 

In today’s digital-first world, passwords are keys for unlocking the information you desire. A password is a single key shared between the user and the service. It is often the only thing hackers need to access user bank accounts, social media information, and other sensitive data. 

As the number of online services grows, remembering multiple complex passwords has become increasingly challenging, especially if you don’t use password managers.

Studies in recent years have shown that people are using passwords incorrectly. For example, IBM’s global survey found that 82% of respondents reused passwords at least once. Even worse, 21% reuse the same username and password for every new account. This poses a serious security risk. According to the Verizon Data Breach Investigations Report for 2024, stolen credentials account for a whopping 77% of basic web application attacks. 

Fortunately, passwords are not the only authentication solution out there. There is a range of passwordless authentication methods at our disposal, and the technology supporting them has been available for some time now.

In this article, we will discuss passwordless authentication solutions for the web, how to use them, their benefits and pitfalls, and how they improve security and user experience.

Authentication is the process of verifying that the user is who they claim to be. There are three common authentication factors:

When users register for a service, they usually need to provide a username or email address and a password. Identification occurs upon login, when a user enters a username/email address, and authentication occurs when users prove their identity with authentication factors. For example, users are authenticated when they provide their username and correct password. Permissions of the service are then granted based on their proven identity.

Two-factor authentication (2FA) or multi-factor authentication (MFA) is a process where the service checks for two or more authentication factors during the user authentication process. For example, along with the password, the user has to click on a link in an email or enter a one-time passcode received via a text message. Multi-factor authentication ensures that even if one factor is compromised, unauthorized access is still unlikely.

A password is secret data, typically a string of characters, usually used to confirm a user’s identity. Using passwords, in general, is not a bad concept. Implementing password-based authentication is fast and simple and gets the job done. 

However, fast and simple as it may be, using passwords as a single point of user authentication can be insecure. There are ways to improve password security, from validating the password’s length and character diversity to requiring special characters, for example. We can also scramble the password, for instance, by salting and peppering it upon saving it in the database. This modifies the password by adding a set of characters and encrypting it with a one-way function to make it unrecognizable and hard to decrypt. 

The second problem with password-based authentication is the people factor.

Even worse, if the leaked password is the same as the user’s email password, the hacker can access all services connected to that email. For example, they could request a password reset on all services connected to the user’s email and set a new password.

One way to prevent this is two-factor authentication, commonly known as 2FA. The first authentication factor is a password, and the second one can be email or text message confirmation, device authentication, or similar methods. This improves security, but the process is more complicated for the user.

We’ve concluded that password-based authentication is not the best option, either from a security or user experience standpoint. Fortunately, there are also passwordless authentication methods. Choosing which one to use will depend on the needs of the application you are building and whether you need to prioritize security or the user experience because one often comes at the expense of the other.

User authentication can be done through a third-party service provider, for example, by implementing the OAuth2 protocol. When a user requests authentication, they are redirected to the third-party service provider. The service provider performs the authentication, creating a session for the user.

This passwordless authentication method is simple to implement and simple to use from the user’s side. Its most common implementation is login via Google or Facebook. Using this approach removes the need to store the passwords on your server, as a third-party service handles that part, but in the end, the service still has to validate the user. 

One drawback of this passwordless method is user privacy concerns, as some users may not be happy with linking their Google or Facebook accounts to your application and sharing their data.

Magic links are a token-based passwordless authentication solution that uses a unique, time-sensitive URL, which provides a token to serve as a credential for user authentication. The magic link is sent to the user’s registered email or phone number. When a user clicks on a magic link, the embedded token is validated against the server to authenticate the user’s identity. This process, by design, eliminates the traditional risks associated with password-based authentication and simplifies the login experience.

Each magic link is a one-time authentication, somewhat similar to a one-time password (OTP). The major difference is that unlike OTP, where the user has to type in the password they received, with a magic link, they don’t need to input any information, as the token will be extracted from the link itself.

The magic link approach offers a solid passwordless experience. But is it safe? Magic links tend to be valid for a short period, meaning the attacker has only a small window of opportunity to intercept one. In essence, magic link authentication is as safe as the service the magic link is sent to, as that service performs the user authentication. If an attacker gets into that service, entering the service that uses magic links is as easy as re-login.

OTP or one-time passwords are mainly used as part of multi-factor authentication, not as a single authentication method. During the login flow, the user receives an email or text with a unique combination of characters called a one-time password. This authenticates the user for a single login session. In addition to email and texts, there is a third option – authenticator apps like Google Authenticator, Microsoft Authenticator, and various others.

This likely won’t present much of an issue for an average user, but can become very challenging for an elderly person or someone with a disability. In any case,  it is always good practice to allow users to paste the copied one-time password into the application.

The security and user experience of this method can be slightly improved by implementing WebOTP API – an extension of Credential Management API. The WebOTP API provides a streamlined user experience for web apps to verify that a phone number belongs to a user when using it as a sign-in factor. The downside is that the support is not available across all major browsers, so some users will not have access to this user experience enhancement.

The flow is straightforward – a user enters a username, email, or phone number used for the service, and then they receive the one-time password via email or text, which serves as an additional authentication factor. With an authenticator app, the user needs to open the app on the linked device and enter the OTP into the login form, which is then sent to the server for verification.

In the case of WebOTP API, if the text message is formatted in a defined way, the browsers that support this can automatically prompt the user to enter the one-time password into the login flow. The security is slightly improved with WebOTP API as the domain part will render phishing attacks impossible since the OTP is tied to the domain.

Passkeys are the beginning of the end of passwords. They are the most secure way of user authentication and provide a seamless experience – a significant step toward a passwordless future. Most people already own and use the technology that can be used for authentication through passkeys. For example, this would be a fingerprint reader or a facial recognition system like Apple’s Face ID or Android facial recognition. Another example is software-based solutions like a browser profile, such as a Google Chrome browser profile.

During the registration process, the user associates the public key with the account, and upon login, the public key is verified against the user’s private key on the platform authenticator.

The perspective in this passwordless solution is that the server does not need to know who the user is specifically, just that they are the same one who created the account, and that part is verified on the platform itself. This means that the fingerprint used for verifying the user in the authentication process never leaves the platform, and it is not shared anywhere.

What happens if I lose or replace the device that contains my passkey credential? Since passkeys are tied to a single device, users need to register multiple devices to ensure access to the application if one of them gets terminated. This can pose a user experience problem, as now the user has to own and register multiple devices.

Here is where large platforms and operating systems come into the picture. They use their own secure channels to sync passkeys across multiple user devices in the background, making them available across all of the user’s compatible devices. 

For example, Apple uses its iCloud Keychain, and Google uses Google Password Manager. The downside to this passwordless experience is vendor lock-in because it is complicated to move out of a company’s ecosystem if you decide to make a switch. Moving to another passkey manager would require changing all passkeys on all services.

WebAuthn (short for Web Authentication API) provides a passwordless authentication method using hardware or software-based authenticators like USB security keys or fingerprint readers. An extension of the Credential Management API, it can provide your users with a more secure and user-friendly authentication process. 

The API specification enables applications to use strong and secure authentication methods for user registration and the login process. It enables passwordless authentication and secure multi-factor authentication (MFA) without needing a text or an authenticator application. 

These authenticators rely on public-key cryptography to provide secure registration and authentication of accounts. To achieve this, the user has to complete a sequence of steps to associate an authenticator device with their account, which generates a public-private key pair. Using this way of passwordless authentication, by nature, has some benefits:

The key concept in understanding passkeys is public-key cryptography or asymmetric cryptography. We can explain this simply with a color-mixing analogy. When you mix two colors, you get a new color. However, guessing the exact colors that created the new one is nearly impossible.

Complementary colors are pairs of colors that, when combined or mixed, cancel each other out (lose hue) by producing a grayscale color like white or black. For this example, we will use a color mixer that produces a complementary color of the starting one. In this example, we assume that mixing colors is a one-way function as it is fast to mix colors and output a third color, and it is much slower to undo.

Let’s say two parties, Alice and Bob, want to start an encrypted conversation. Alice starts by selecting a color: red.

Step 1: Alice mixes the private red color with the color mixer to create a complementary color—cyan. She then sends the cyan to Bob.

Step 2: Bob wants to send Alice a yellow message, so he adds yellow to the mixture Alice sent him, creating a green color, and sends it to Alice.

Step 3: Alice adds her private red color to the mixture, and since this is a complementary color to the cyan, it cancels the cyan out, leaving the clear yellow color – Bob’s message.

Suppose a third person wants to listen in on the conversation at any point. The information they receive will be useless, as it is encrypted. The key ingredient for decrypting it exists only in Alice’s private space. This is also why private keys should always be safely stored and never shared publicly.

This oversimplified key exchange example is used just for explanation purposes. The real use case is more complicated but shares the same concepts. One of the key points is the idea of mixing the colors, as this process is “non-reversible.” 

In theory, reverse-engineering a private key is possible, but it would require significant resources. The encryption algorithm used is one-way, meaning it can realistically only be cracked through a brute force attack, which involves guessing the private key. This process is so resource-intensive that it’s simply not worth the effort.

One of the most common algorithms used for asymmetric encryption on the web is RSA. It is used in web browsers, email chats, VPNs, and other communication channels. It has been used multiple times since you opened the browser and navigated to this blog post.

The technology behind passwordless authentication methods has been around for some time, and big players like Google and Microsoft have already adopted it. The main goal is to improve both security and user experience, which can be achieved by following the defined standards. 

Improving the user experience and simplifying the registration process are key ingredients in acquiring new users. That said, deciding which solution to implement depends on the project you are working on – there is no universal solution for all applications. Sometimes, the emphasis is on the user experience and sometimes on raising the security level. Higher security, unfortunately, translates to more steps, which complicates the flow, but by taking the right steps, we can implement the solution so that users can easily authenticate and enjoy the passwordless experience.

The Web authentication API is ready to be used by developers, and it is already backed with a lot of examples on the web, implemented in various programming languages. Don’t be a late adopter.

And in case you need help boosting your security posture, check out our cybersecurity services.