Getting “Passwordless” right: 7 mistakes you should avoid
The future is passwordless – at least that is what current market developments speak for. Even better digital identities and available biometric technology facilitate secure access to online services without the need for cryptic strings. But there are several pitfalls on the way to a passwordless infrastructure. Guest author Al Lakhani shows what to avoid.
Removing the password is not a question of “if” but of “when”. Up to 82 percent of cyberattacks are currently due to compromised passwords. Besides the fact that even long and complex passwords can still be cracked by brute force with the right computing power, we humans are the most significant risk factor. Phishing and insider threats are at an all-time high due to COVID-19, which is not likely to change soon. Consequently, that means we need to follow the path to abandoning the password with ultimate consistency. After all, solutions such as 2-factor authentication (2FA) can be circumvented by clever phishing, and password managers just as single sign-on (SSO) only hide or postpone the problem.
The good thing is: There are already solutions available today that replace the need for passwords altogether. Some providers manage to switch from knowledge-based factors (passwords) to factors you own (smartphone authentication) and inherent factors (biometrics) when it comes to authentication. In the case of the knowledge-based factor, it is always uncertain whether someone else also has this knowledge. In other words, it is unknown to a user whether another person also knows the password. With something like a personal smartphone used for authentication, you can be sure that no one else has it in their hands, not to mention a face as a biometric factor.
Nevertheless, there are pitfalls in the implementation of passwordless technology that every developer should know and avoid. The goal should be to integrate passwordless authentication as part of a zero-trust architecture. Zero Trust is based on some basic principles:
- All data and devices are considered resources. Devices of employees, for example, must be considered in the security concept if they can be used to access company data.
- Communication must be secure, whether inside or outside the network. Authentication and encryption must always be part of the communication.
- Access to individual company resources may only be granted on request and is then limited to the respective resources.
- Access is determined by clear guidelines that include identity, system and other attributes.
- Internal and related systems are subject to continuous monitoring to maintain the highest security standards.
- The authentication of the user must be strictly controlled before granting access.
In order to achieve this gold standard of cybersecurity, some measures are necessary for the development. To avoid errors in advance regarding passwordless authentication, the biggest pitfalls are summarized here in 7 points:
“Passwordless Experience” differs from “truly passwordless”
Not every seemingly passwordless approach is truly passwordless. Many solutions simply try to hide the password from the user in the user experience – this is called “passwordless experience”. Single Sign-On (SSO) is one example: Here, a single password is repeated in the background, invisible to the user. This ensures a smooth user experience but does not solve the actual fundamental problem: How do you know that nobody knows your password? Once the password has been compromised, access to all resources is granted, and all doors are open to the attacker — even to other individual user accounts. So, the risks of weak authentication remain.
The goal of passwordless technology is not to reduce the number of passwords or hide them from the user but to create a completely independent alternative that does not require any passwords at all. Certainly, the “passwordless experience” does have advantages, such as the fact that a user only has to remember one password. However, it is not a truly passwordless technology, and all the disadvantages of passwords in general remain. “Truly passwordless” means that the authentication process only takes place through a number of strong authentication factors, such as ownership or inherence, and completely dispenses with knowledge-based factors. Thus, “truly passwordless” technology is fundamentally more robust and, incidentally, avoids all password-based attack vectors such as phishing or credential stuffing.
Do not use credentials that are not bound to a specific device
A good step towards passwordless technology is undoubtedly to store the login data for a user account on a device. This way, the user has to prove that he is in possession of the device in order to log in. So, if you want to make sure that ownership can be clearly assigned to a particular identity, you have to make sure that the credentials are bound to a specific device. One solution is that a specific person can only open an Authenticator App on the device through an inherent factor. For example, when accessing a system, the Authenticator App on a device is pinged – but before the user can authenticate himself with his device, he must prove through biometrics that he is also the rightful owner of the device. By chaining the factors, this method exceeds the security of a Fido stick, which can again fall into strangers’ hands and ensures that the factor possession cannot be abused by cloning the device.
Do not use implicit trust when adding new devices
Device-based authentication is, as described above, a reasonable approach to avoid knowledge-based factors. But what happens if an attempt is made to bypass the system by adding a new device to it. To ensure unambiguous authentication, the identity must be securely confirmed. In other words: confirmation in the e-mail inbox is not secure enough. An e-mail address can be compromised, making it easy for attackers to circumvent the identity lock-in when restoring a user account or setting up a new device. The method of setting up new devices should be as strong as the authentication method. The most convenient way to achieve this is certainly for users to approve the addition of a new device with the current authentication device.
Do not use weak authentication factors
This point may seem obvious, but it is an important aspect and the central foundation: No weak authentication factors must be used during the entire process. In practice, this often looks different. Far too often unnecessarily weak authentication factors such as SMS, Magic-Link, manual input or a knowledge-based factor are used unnecessarily. This should be avoided if possible. Strong factors like possession and control of a cryptographic key stored in a secure smartphone element is the preferred way to go.
Avoid shared secrets
Cybersecurity companies are not immune to hacker attacks either. A certain residual risk always remains. Suppose an attacker should ever gain access to an identity provider (IDP) that stores the credentials of all created identities in a central database. In that case, the attacker will have access to all customer systems. It does not matter whether the credentials are stored on the company server or the service provider’s server – a data leak would have the same devastating consequences. But there is a way out: Instead of relying on central and supposedly secure databases, credentials should be created as asymmetric keys. In this way, the credentials can be stored decentrally on the smartphone’s security chip. This means that an attacker cannot access credentials even if he gains access to an IDP.
Do not go for server-based account recovery
Even in a passwordless technology, accounts can be lost – for example, due to loss or damage to the ownership factor. Secure account recovery is one of the most essential aspects when it comes to achieving password-less authentication and not unnecessarily undermining its benefits. It is crucial that only the real user has access to the recovered data set. This is only possible if the identity is securely authenticated and the recovery is user-side. At no time should the recovery take place on the server side. Finally, server-based insider attacks and credential harvesting should still be excluded.
Always consider security risks holistically
A common mistake in strengthening the security architecture is that often only a single aspect is adapted. For example, companies strive to improve access control and align their measures with this goal without considering the other components of the architecture. Besides, there is a constant conflict of goals between security and user comfort, which should not be ignored either. In a silo-like view, both factors lead to the optimization of one function at the expense of another security feature. Particularly when protecting corporate IT, developers should always make sure that they are aware of the potential threats that can arise in adjustments. Threat models, such as that of IDEE, can help make a comprehensive assessment and make appropriately informed decisions.
Conclusion: An all-round secure feeling
Companies that want to improve their authentication will not be able to avoid relying on passwordless approaches. The change is not as complicated and costly as it may seem at first glance. The points mentioned above must be considered during implementation. While the choice of the approach depends on the company’s individual risk tolerance, most companies are well advised to rely on an MFA with password-less authentication. This usually allows a balance between security and usability to be achieved without unnecessarily increasing costs. If such an approach is chosen, developers need to make sure that aspects such as registration, authentication method security, and recovery options are designed to be secure.