To Password or Not to Password: That Is the Question
Passwords remain the default method of user authentication, but the question is for how long? It is becoming more or less an established fact that passwords are insufficient to prevent software threats. The statistics on the number of password breaches and their consequences prove this point. Passwords pose a serious security risk, and even if used together with multifactor authentication (MFA), they are incredibly vulnerable.
All these security issues are driving efforts toward a passwordless approach to modern application sign-on. In this article, I will explain why a no-password approach is better for increased security. But who needs it, and how and when should an organization go passwordless?
The Password Dilemma
First, let me break down why passwords are becoming a relic of the past.
A password can be viewed as a shared secret — it’s a string of characters that should only be known by the user, but provided to an application or service, which stores them in a hashed or encrypted format. So every time the user enters the password, the app hashes or encrypts the given combination of symbols and compares it to the initially provided password.
While hashing can guarantee some password protection, several other problems occur on the user side.
Due to the knowledge-based nature of passwords, the first issue is the passwords themselves. It is no surprise that with so many passwords to remember, many people choose sequences that are easy to recall. This is most often a phrase or a combination of numbers such as 123456. Unfortunately, such passwords are easily guessed by computers that use large dictionaries and process millions of words per second. This prompts administrators to require more complex passwords that include special characters, upper and lower case letters or numbers. Some may require passwords without actual words.
However, a complex password can be more secure, but remembering it becomes another problem. Even if a person can recall one long and random sequence of characters, they are more likely to reuse this seemingly safe password across different web apps. But if one web app is compromised and the password leaked, the attacker could access the user’s accounts across many more web apps.
Moreover, passwords are frustrating. They create friction and degrade the user experience. And if a user forgets a password, they might experience a difficult password reset process. Users may sometimes be forced to contact an administrator or support, which takes additional time and effort.
The use of password managers can alleviate some of these issues. They keep track of passwords for different accounts so the user doesn’t have to remember them. However, this requires the user to put all their eggs in one basket — if the password manager is breached, all the passwords are compromised.
Passwordless Authentication: The Alternative to Passwords
Going passwordless eliminates the risks associated with passwords. This doesn’t mean that the user isn’t authenticated. Instead, this method involves using other options to identify the user without relying on their memory or storage safety.
The most common approaches are:
- Email and SMS authentication
- Authenticator applications
- Authentication devices and fobs
- Different forms of biometric authentication
Let’s look at them more closely:
When using email and SMS authentication during a login process, users receive a numerical code, QR code or a link to their registered email address or phone number. These options are fairly secure and easy to implement. Therefore, they are the most popular. However, this type of authentication is associated with some security risks as they are vulnerable to phishing attacks.
The second most popular method is the use of an authenticator application (Google Authenticator, Duo and Yubico Authenticator App are a few examples). These authenticator apps constantly generate a one-time password (OTP) code that the user uses to authenticate. The authenticator app is in sync with the user’s account — the OTP is only valid for a short period of time, and once it expires, the specific code cannot be used to authenticate.
Some authentication apps take this a bit further. Using Duo, for example, the app requesting authentication can initiate a push authentication request so the user gets a notification prompt to authenticate in the Duo app.
The last option, the use of authentication devices and fobs, is phishing-resistant and most secure. It uses a hardware token coupled with the WebAuthn standard. Yubico, with its YubiKey, is one of the leading technologies in this area and offers several types of hardware authenticators. With this option, a unique key pair is generated for each app the YubiKey is used for. The result is a solution where a “phishing app” cannot use the authentication details for the real app as the generated key pair wouldn’t match.
More and more technologies are entering the passwordless market. Lots of them are based on the inherence authentication factors (something that the user is) such as fingerprints, voice recognition, typing pattern recognition and more. Some companies developing these authentication types are Beyond Identity, Hypr and Secret Double Octopus, to name just a few.
Eliminating login passwords can improve the security of your systems and mitigate the risks associated with passwords. It can also improve the user experience and reduce friction for users and administrators. However, the implementation of the passwordless approach should not be done only for the sake of it.
First, stakeholders should agree on the objectives of the passwordless approach. Be it more robust security or enhanced user experience, all parties involved must have a clear plan on how to run the implementation. It should also stem from a thorough analysis of the efficiency of current authentication methods, whether your existing system is capable of handling passwordless, and what should be done step by step to achieve it.
Second, it is important to understand the popularity of passwords: They are easy to implement and need no prerequisites. However, with passwordless, these prerequisites should be in place, be it a mobile phone with an authentication app, authentication device or keyfob. Corporate users can typically be supplied with pre-registered authentication devices, but it requires time and patience to embrace a new process.
Third, as with other big projects, it is necessary to start small. Start by implementing passwordless authentication in smaller test groups and continuously monitor the project’s success.
In the meantime, consider using an opt-in approach or enforcing more robust authentication mechanisms. You can also start implementing passwordless options with critical services and data using step-up authentication.
There are many things to consider, but passwordless is the future. Prepare for it now.