Authentication methods

The simplest authentication method is using a username and password. During registration, the user sets both credentials and later uses them to sign in. It’s simple and easy to understand. However, passwords of course come with several risks. Users may choose weak or easy-to-guess passwords, reuse passwords that have already been leaked in previous breaches, forget them and require resets, or fall victim to phishing attacks. In addition, if a database containing password hashes is compromised, user accounts beyond just your website may also be at risk. A more common modern approach is to allow users to link their account to an email address. While this does not significantly improve security on its own, it enables password recovery through temporary links or verification codes sent by email. It is also common to use the email address itself as the account identifier, since it is globally unique and less likely for users to forget.

Because passwords alone are often not strong enough for secure sign-ins, more websites now add a secondary authentication method alongside the password. This is commonly known as two-factor authentication (2FA) or multi-factor authentication (MFA). Common secondary methods include one-time codes sent to the user’s phone number via SMS and codes generated by an authenticator app on a mobile device. While these methods are relatively weak on their own, combining them with passwords provides a reasonable level of security for most users. In practice, I think it’s better to view many secondary authentication methods as mechanisms designed to slow an attack down long enough for the legitimate user to reset their credentials. If email-based authentication is used to verify user identity during password reset flows, however, it is generally best to avoid using it as the secondary factor. If both the password and email verification are required to sign in, but access to the email account alone is enough to reset the password, then the password itself provides little additional security. You also have to consider whether email-based authentication alone provides sufficient security guarantees for password resets. In general, you should require a second factor during the password reset process.

Another option is to ditch passwords altogether. A common implementation is to use a flow similar to email-based password reset systems, where the user receives a one-time code or link. Because the server controls the complexity of the code or link, these methods are often more secure than passwords. However, especially when password managers are used, they can be slower and more frustrating than traditional password-based authentication. The main risk is that the email code is only as secure as the user’s email account and device. While these methods are not as secure as password-based authentication with 2FA, since they only require a single factor, they may still be secure enough for the majority of websites.

Finally, there are passkeys. These are secure credentials stored on a user’s device or in a password manager that use public-key cryptography to authenticate users. They allow users to sign in to websites using a single master password or their device biometrics. Passkeys provide one of the highest levels of security because they are resistant to brute-force attacks and do not directly share credentials with websites. They are also fast and convenient. However, passkeys are still relatively new, and non-technical users may not yet be familiar with them.

You also have external hardware tokens or security keys, such as YubiKeys. Most modern ones support passkeys, but they are also commonly used as a secondary authentication method alongside passwords in corporate environments. The user connects the key to their computer to verify possession of the device, and optionally, verify their identity using a PIN code or biometrics. When using them with identity verification, they already provide much stronger security than passwords so in practice there's really not much benefit in using them as a secondary authentication method to passwords.

The authentication method you choose will depend entirely on your application’s security requirements. In general, avoid using an authentication method if you are not confident it provides sufficient security for your application. Users are lazy and will almost always choose convenience over security. In many cases, it is easier to adopt a more secure authentication method from the start than to rely on bot detection, suspicious activity monitoring, and other heuristics afterward. You also need to consider user expectations. How secure do users expect your website to be? Will they blame the platform if their account is compromised because of poor personal security practices?

For a casual forum or browser game, password-based authentication is likely sufficient. However, if your users are primarily everyday users and there are meaningful incentives for attackers to take over accounts, you should use a more secure login method. At that point, you generally have two options: add a secondary authentication factor to passwords or adopt a passwordless approach such as email-based sign-in. If accounts need a particularly high level of security, consider using passkeys. If you are building a system from scratch, I recommend supporting both email-based authentication and passkeys, allowing users to choose either method to sign in. Email-based authentication is familiar and easy for most users to understand, while passkeys are typically faster and more secure. The default setting should allow users to sign in using either method but you should also consider providing security-conscious users the option to require passkeys exclusively.