Passwordless Connections Best Practices

You can implement Passwordless authentication by redirecting to Auth0's Universal Login or by embedding login in your application. We always recommend that you implement Universal Login. To learn why, read Centralized Universal Login vs. Embedded Login.

To learn how to implement Passwordless authentication, read the following articles:

• Passwordless with Universal Login

• Passwordless Authentication with Universal Login

• Passwordless Authentication with Embedded Login

Auth0's passwordless implementation enables authenticating users with a single factor. That single factor can be one-time-use code sent by email or SMS, or a magic link sent by email.

Although using email or SMS can be more secure than a weak password, both have known issues:

• Phone numbers are not sufficient for user authentication. The SS7 phone routing system used by cellular networks has verified weaknesses which have led to it not being recommended as an authentication factor. There are many attack vectors available, ranging from the use of social engineering, to swapping SIM cards and buying access to the SS7 network.

• Email address possession is not sufficient for user authentication (aliases, forwarding, multiple users in one account are all examples). Email providers vary in their security practices and some do not require any establishment of a user's identity. SMTP is a very old protocol, and many providers still route SMTP traffic unencrypted leading to an increased chance of an interception attack.

For these reasons, we recommend that if you use passwordless authentication, you also implement Multi-factor Authentication (MFA) with a different factor when the user performs a security-sensitive operation.

An example of what a possible phishing attack could look like is as follows:

1. The user clicks a link in a malicious email or website.

2. The user lands on the attacker's fake site, where they are prompted to enter their phone number to authenticate.

3. The user enters their phone number, and the attacker enters the same phone number in the legitimate application.

4. The legitimate application sends an SMS to the user.

5. The user types the one-time-use code in the attacker's website.

6. The attacker can now log in to the legitimate website.

To decrease the chances of success for this attack, the user should expect that the SMS clearly identifies the application. You should configure the SMS template so it mentions the tenant name and/or the Application Name:

Your verification code for accessing's Acme @@application.name@@ is @@code@@

Auth0 has the following protections against brute force attacks:

• Only the most recent one-time-use code (or link) issued will be accepted. Once the latest one is issued, any others are invalidated. Once used, the latest one is also invalidated.

• Only three failed attempts to input any single one-time-use code are allowed. After this, a new code will need to be requested.

• The one-time-use code issued will be valid for three minutes (by default) before it expires.

• If a passwordless user has been blocked administratively, Auth0 will not send any OTP codes over SMS or email until the user is unblocked. This behavior protects your SMS and email providers from receiving unnecessary requests.

The one-time-use code expiration time can be altered at Auth0 Dashboard > Authentication > Passwordless.

User enumeration is when a malicious actor uses brute-force techniques to either guess or confirm valid users in a system.

When Disable Sign Ups is enabled, your application may become vulnerable to user enumeration attacks. Auth0 recommends that you do not enable this setting to ensure the maximum security of your application and its users.

If you do enable Disable Signs Ups, Brute-force Protection may mitigate the threat of some of these attacks, but it does not fully protect your application.

Users might want to authenticate using different passwordless factors during their lifetime. For example, they could initially sign up with an SMS, and later start authenticating with an email. You can achieve that by enabling them to link their different profiles using account linking.

The /passwordless/start endpoint has a rate limit of 50 requests per hour per IP address. If you call the API from the server-side, your backend's IP may easily hit these rate limits. To learn how to address this issue, read the Rate Limiting in Passwordless Endpoints section of Using Passwordless APIs.