The Problem with Passwords

A static password is a secret string of characters used repeatedly over time by a user to authenticate to a particular protected resource. Static passwords are widely used today but have several drawbacks. Short passwords may be guessed by brute force attacks which try every possible password. Long passwords can be difficult for users to remember, but writing them down makes them more prone to being stolen. If a username and password are stolen, they can be used by someone far distant from the account owner, who may not realize the password has been compromised until it is used to do something unauthorized. Worse, if the compromised password has been used across multiple sites, its theft can put them all at risk. The introduction of single sign-on makes the use of static passwords more problematic in the sense that a stolen password may grant access to many systems.

Stronger Forms of Authentication

To avoid the weakness of static passwords, there are several stronger forms of authentication that can be used. One widely used mechanism has been to send a one-time password (OTP) to a user via SMS text message or email. The OTP is often a numeric code that is generated by an application and sent to the user at the time of authentication. The user enters the OTP into a login screen to complete the authentication.

Alternatively, a one-time password can be generated by an application on a user device or by a specialized hardware OTP display token. As the name implies, a one-time password can only be used once, making it more difficult for an unauthorized party to use a stolen OTP than a stolen password. Examples of OTP-generating phone apps at the time of writing are Google Authenticator, Duo, Authy, and VIP Access. Apple has also added a built-in OTP generator capability in iOS 15.1. Symantec, Gemalto, and RSA are examples of vendors that produce a hardware OTP display token that generates and displays a one-time password. For some users, a phone is more convenient for OTP generation because they tend to always have their phone with them.

Another approach involves the use of a pair of cryptographic keys. A private key is securely encapsulated in a device such as a smartcard, hardware authentication device, or mobile phone. The entity wishing to authenticate the user sends a challenge nonce to the authenticator device. The secret key encapsulated in the device is used to sign the challenge nonce. With some multi-factor authenticator devices, the user has to enter a PIN or provide a biometric factor to unlock the device before it will sign the challenge nonce, providing a layer of protection against theft of the device. The authenticating entity receives a message back from the device with the signed challenge nonce and validates the signature, using a public key that corresponds to the private key on the device. The public key would have been previously registered during a setup step. If the signature is valid, this process indicates that the user (subject) attempting to log in possesses the authenticator device associated with the account. With this approach, authentication is based on possession of the device with the key as well as a factor (such as a PIN or fingerprint) to unlock the device.

An industry standard was defined for such hardware security keys called Fast Identity Online (FIDO) Universal Second Factor (U2F).ⁱ This initial protocol has since been extended with newer protocols that add additional features, known collectively as FIDO2. At the time of writing, Yubico provides many types of security keys compliant with FIDO U2F and FIDO2 and is a well-established vendor of such products. Newer offerings are also available from vendors such as Google (Titan key), Thetis, TrustKey, and Feitian.

Biometric factors such as fingerprints, facial scans, retinal scans, and voiceprints can serve as stronger forms of identification. Apple’s Face IDⁱⁱ and Touch IDⁱⁱⁱ are examples of biometric authentication, and the Android framework also enables biometric authentication.^iv

It’s worth noting that knowledge-based authentication (KBA), which involves answering security questions, has similar risks to passwords. Answers can be guessed, sourced from public information, or stolen and then used by a remote entity without the owner’s knowledge. The strength of authentication methods can be classified, and one example classification scheme is the NIST 800-63 Security standard^v which defines criteria for three levels of authenticator assurance.

Session Timeouts

An identity provider may allow the configuration of multiple forms of authentication along with a classification or level of authentication assurance for each. A user’s authentication session may then include information about the authentication mechanism(s) used, an authentication assurance level or authentication context class, and the session expiration. If an identity provider supports authentication sessions at different authentication assurance levels, you should consider shorter session timeouts for elevated sessions which provide access to more sensitive resources. Shorter session timeouts for more privileged sessions reduce the chances of highly privileged sessions being hijacked for malicious purposes and align with the security principle of least privilege.

Requesting Authentication Mechanisms

Applications may need a way to request an identity provider use a particular class of authentication mechanism to achieve a desired level of authentication assurance. This can be done with an authentication context class reference. An authentication context involves several factors, such as the identification processes used to create an account, the protections against credential compromise, and the authentication mechanism used. An authentication context class represents a set of authentication methods. An authentication context class reference is an identifier for an authentication context class. Authentication context classes and class references are often defined by an identity provider, but may be worked out by a service provider in conjunction with an identity provider. The following sections explain how applications can request a particular authentication context class and how identity providers can provide claims to convey the authentication context class reference and/or authentication mechanism(s) used.

Step-Down Authentication

To align with the security principle of “least privilege,” a user should operate at the minimum privilege level necessary for a particular task. In an environment where sessions can exist with different assurance levels or authentication contexts, with higher-level sessions that enable access to more sensitive resources, users would ideally be able to “step down” their session’s authentication assurance level when they no longer need the elevated privileges. This reduces the damage that can be done if a session is hijacked as well as the risk from simple human error when operating at a higher privilege level. Step-down could be implemented with an explicit mechanism, though we have not seen this done in our experience. It is probably more practical to simply rely on short session timeouts for more privileged sessions as well as user logout for immediate termination of a session.

Deployment

There are several deployment considerations worth mentioning for multi-factor authentication (MFA). MFA of any form is an improvement over static passwords which can be stolen through a variety of means including phishing, social engineering, and malware. However, security, usability, maintainability, cost, and recovery are all factors to consider when choosing one or more forms of MFA for your project.

Sending one-time authentication codes to users via SMS messages is widely used and easy for many users to set up and use. If a user’s phone is broken, lost, or stolen, the user only has to have the cellular company associate their phone number with the SIM card in their new replacement phone. Once this is done, all the user’s SMS messages will come to the new phone, enabling the user to authenticate to applications using the new phone.

The use of SMS messages for authentication can involve a short delay as the user must wait for the code to arrive, and some users may incur a charge to receive SMS messages. A user must also have connectivity to receive the message. This may be a problem in remote environments, environments that restrict use of cellphones such as hospitals, or shielded environments such as underground data centers. Once the message is received, the user must enter the code from the message into a login screen. This is reasonably convenient when logging in to a separate device, such as a laptop, but can be more cumbersome for an app on the same phone.

At the time of writing, the security of SMS codes sent to phones is threatened by several types of attacks. In a SIM-swapping attack, an attacker impersonates a cellular customer (or bribes a cellular company employee) and requests that the victim’s phone number be associated with a new SIM card possessed by the attacker. This enables the attacker to intercept the victim’s calls and SMS messages. Other attacks have intercepted voice and SMS communications on cellular networks by targeting Signaling System No. 7 (SS7), a protocol layer in the infrastructure that provides connectivity between mobile phone networks. Such attacks are not yet widespread, but may increase in the future. One approach to mitigate this risk is to require the user to re-enter their password when they enter the code, but users may find this annoying, especially if they do not understand the purpose. Your projects should evaluate the current status of SMS attacks before deciding to rely on SMS codes for multi-factor authentication.

Specialized hardware authenticator tokens that generate and display a one-time password have been used in enterprise environments but are becoming less common. They avoid the vulnerabilities associated with SMS messages, but are less convenient because the user has one more item to carry around. The devices can break, get lost, stop working due to a drifting inner clock, or run out of battery and the ongoing cost of replacing devices can be substantial, in one author’s experience. In addition, if it takes time to send a new device to a user, they may not be able to log in until they receive the new device and go through an administrative step to associate the new device with their account.

Using an application on a user’s mobile phone to generate a one-time password avoids the drawbacks associated with SMS messages and specialized authenticator tokens, but has other issues. There are many OTP-generating applications and each of the different websites a user visits may only support the use of a particular one. This requires users to remember which generator application to use with each website they log in to. Furthermore, if a user’s phone is broken, lost, or stolen, the user may temporarily lose the ability to log in while they get a new phone, install the generator apps on their new phone and go through an administrative process at each website they use to authenticate them through other means, remove the old phone, and reenroll with their new phone. The same applies if a user inadvertently deletes the OTP-generating application from their phone. For applications where frequent access might be critical, such as stock trading applications, being locked out of the application until a new phone is registered could have significant negative impact to users.

Authentication devices with cryptographic keys are becoming more common. The authentication secret in this case, a private key, never leaves the device. This means a user cannot be phished or tricked into revealing it. Some devices employ a fingerprint reader such that a user simply touches the reader to unlock the device for authentication. This provides a convenient user authentication experience. On the negative side, this solution involves a separate device which a user must remember to have with them when they need to authenticate. In the past, a given website may have only supported specific security keys or keys from a specific vendor, potentially requiring a user to have more than one across different websites. The FIDO2 protocols and interoperability testing should help alleviate this issue by facilitating interoperability between different vendors’ security keys and different websites needing to authenticate users. Like phones, these devices can break, get lost, or be stolen, and a user may temporarily lose the ability to log in if this happens.

With OTP-generating apps on phones or hardware authentication devices, an administrative process is required to deregister an old device and associate a new device with a user’s account. If the old device is available and functioning, the user can authenticate with it in order to perform this administrative step themselves. If, however, the device is not available, a user cannot authenticate. Some sites provide the ability to download a set of backup codes for this scenario. The backup codes are system-generated so they are typically long, unique to a particular site, and can only be used once. The use of backup codes, however, relies on the user safely storing the backup codes, noting the site they are for, and having them readily available if their primary authentication device is no longer usable. If a user does not have their backup codes, it is necessary to authenticate them through another means before registering a new device. This is to prevent hackers from bypassing multi-factor authentication by calling up and claiming to be the user and that they’ve lost their phone. In addition, an attacker who is able to steal a user’s backup codes, and password if used, can potentially bypass the multi-factor authentication and take control of the user’s account.

Biometric factors have the drawback that if used for authentication and compromised or damaged, they cannot be reissued. In other words, a person cannot be issued a new finger if a hacker is able to capture their fingerprint and use it with biometric fingerprint authentication. If a biometric authentication factor is compromised, it is necessary to either change the factors used or change what the authentication algorithm looks for in the existing factors. In addition, with some biometric factors such as a fingerprint scan, it may be possible for an attacker who has stolen a phone to unlock it if the user is asleep or to physically force the user to unlock the phone. As with other forms of authentication, you need to plan in advance for how to recover from likely compromise scenarios.

Beyond security considerations, be sure to consider usability and ongoing maintenance requirements. Testing multi-factor authentication mechanisms and the use of step-up authentication with users who are representative of the target user population is valuable to identify any usability issues before widespread rollout. Be sure to test failure (unsuccessful) cases as well as successful cases. For every failure case, consider what a user would need to do to recover from the situation and make sure it is reasonable. Evaluate authentication devices for their durability as well as likely battery life if applicable to avoid unexpected costs for replacing broken/dead hardware devices. Depending on the type of authenticator chosen, you may have to budget for replacing lost and damaged devices. When replacement is necessary, you’ll also need a process for quickly but securely replacing lost or damaged devices to restore a user’s ability to log in. Be sure to plan for secure distribution, replacement, and revocation of authentication mechanisms as part of any deployment.

Summary

Some forms of authentication are considered stronger than others. Passwords are a weak form of authentication, whereas the use of one-time passwords generated on a device or multi-factor cryptographic authentication devices are stronger forms of authentication. Multi-factor authentication requires the use of multiple authentication factors, typically something you have as well as something you know. Step-up authentication is the act of authenticating with a stronger form of authentication which elevates a previously existing authentication session to a higher level of authentication assurance. Authorization policy may require a session to be at a specific level in order to access sensitive resources. Both OIDC and SAML 2 allow applications to request that an identity provider authenticate a user with a particular authentication context class of authentication mechanisms and to receive information about the authentication context class and/or authentication method(s) used to authenticate a user. You should also plan to terminate higher-level sessions in a timely manner via shorter session timeouts or logout, and, conveniently, logout is the topic of the next chapter.

Notes