Passwords are a hassle for users, so you are thinking about going passwordless. While there are many passwordless authentication solutions, most of them still require usernames. Remembering and entering usernames is still a hassle for users, but a necessity for most solutions. Learn why usernames are a necessity for these solutions and why nextAuth does not need usernames. This makes that the nextAuth mobile authentication solution excels in user experience while maintaining the highest level of security.
It is generally acknowledged that passwords are a hassle for users, especially when entered on mobile devices. Security dictates that users must choose “strong” passwords, not re-use these and change these regularly. This hassle for users translates in strain on your help desk (users resetting their password) and user churn (users that do not bother anymore). The suboptimal user experience that comes with passwords, combined with their poor security track record, makes that organisations are thinking about a passwordless approach.
Passwordless authentication solutions come in many forms, ranging from (external) hardware tokens, soft tokens to mobile authentication apps. However, most of these still need usernames. In a typical scenario, the user first enters his/her username in a browser and then completes the login using a token or app on their mobile. Remembering and typing in usernames still requires effort from the users. In order to minimise this effort, applications often
- allow for easy-to-remember usernames, such as an email address or phone number;
- offer to cache the username; But, this does not work for devices that are used for the first time, shared workstations or kiosks. In these situations, users will have to enter – over and over again – their username before being able to do the actual login using their token or mobile.
- keep users logged-in forever (see our next blog post on the security pitfalls of such strategies).
A username is a unique identifier for a user. An application must uniquely identify its users for giving user access to their content. But is there a reason for users to enter their username when authenticating?
Brute-force security
When considering classical password-based user authentication, the need for usernames is clear. Even a “strong” password has, on average, an entropy of 28 bit. This limited entropy means that computers can easily brute-force all possible passwords. Hence, you only want to verify a password for a specific user, and not for every user in your system. As such, the probability of a successful brute-force attack does not increase with the number of users in your system. On top of that, you want to limit the number of failed password verifications for each individual user (or at least the rate at which one can try).
For other systems, there is no clear need for usernames. For example, machine-generated tokens guarantee sufficient entropy and are thus not vulnerable to brute-force. The same can be said for solutions that are based on strong public/private key cryptography, such as nextAuth. Solutions based on symmetric cryptography can in principle also guarantee sufficient entropy. However, far too often, the output of these systems is truncated, e.g., the OCRA standard, 6-8 digit One Time Passwords (OTPs). These 6 (8) digits corresponds to an entropy of 20 (27) bit, which can easily be brute-forced by a computer. This means that for these cases, a username is required for security. As such, one can limit the verification to a specific user and the number of verifications for that user in time.
The table below shows the level of brute-force security for the number of users in the system, when under a remote attack. It assumes that the backend is dimensioned to handle all users authenticating simultaneously in one second, i.e., the number of attempts per second for an attacker is the same as the number of registered users. It also assumes a conservative rate limiting of 3 tries per user. In practice, the rate limiting will likely allow for more tries and/or only apply per given unit of time, e.g., 3 tries per user per hour, an exponential back-off strategy. The final assumption is that all usernames are known or easily predictable.
Consider, for example, 6-digit OTPs. In the hypothetical case without a username, all accounts are breached in a matter of minutes. With a username, an attacker can only do 3 attempts for every user. As the system is, by assumption, able to handle as many attempts per second as there are users, the total attack will only take 3 seconds. As such, the attacker is not able to compromise every user, but only a limited number, depending on the total number of users.
Conclusion
It is clear that usernames are a necessity when working with 8-character passwords, 6- and 8-digit OTPs. The nextAuth solution uses public/private key cryptography and is highly secure. It is not vulnerable to brute-force attacks and hence does not require usernames.
nextAuth is a mobile user authentication solution that works completely without passwords or even usernames, yet provides True 2FATM. With the nextAuth solution, users will no longer need to remember or enter any form of username. This means that users can login without hassle from a new computer or use kiosk system that is shared among many users.
