Come, let us hasten to a higher plane,
Where dyads tread the fairy fields of Venn,
Their indices bedecked from one to n,
Commingled in an endless Markov chain!
—Stanislaw Lem, Polish author of science fiction, philosophy, and satire, from The Cyberiad (1965)
Different methods of authentication are not considered equal. The static passwords that still enable access to many Internet services are considered a relatively weak authentication mechanism. Several stronger forms of authentication exist, and their use is recommended to better protect online resources. In this chapter, we’ll discuss the issues with static passwords and how stronger forms of authentication can be used for multi-factor authentication and step-up authentication.
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 message1 or email. The OTP is often a numeric code and is generated and sent to the user at the time of authentication. The OTP is then entered into a login screen by the user to complete the authentication. Alternatively, a one-time password can be generated by an application on a user device such as a mobile phone or by a specialized OTP hardware security token. As the name implies, a one-time password can only be used once, making it difficult for an unauthorized party to use a stolen OTP.
Another approach involves the use of a private cryptographic key that is securely encapsulated in a device such as a smartcard, hardware security token, 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 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. The authenticating entity receives a message back from the device with the signed challenge nonce and validates the signature, using previously registered information, to ascertain whether the user (subject) possesses the authenticator device. With this approach, authentication is based on possession of the device with the key as well as a factor to unlock the device.
Biometric factors such as fingerprints, facial scans, retinal scans, and voice prints can serve as stronger forms of identification but 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.
It’s worth noting that knowledge-based authentication (KBA), which involves answering security questions, has similar risks to passwords. Answers can be guessed or stolen by a remote entity and used without the owner’s knowledge. The strength of authentication methods can be classified, and one example classification scheme is the NIST 800-63 Security standardi which defines criteria for three levels of authenticator assurance.
Multi-factor Authentication
Multi-factor authentication requires the use of multiple authentication factors in order to authenticate. These typically include something you know as well as something you have and/or something you are. The something you know can be a password or passphrase. The something you have may be a device such as a mobile phone or a hardware security token used for one of the authentication mechanisms described in the previous section. The something you are can be a biometric factor such as a fingerprint, voiceprint, or facial scan.
The use of multi-factor authentication reduces the risk if any one factor is compromised. If authentication requires entering a static password as well as a one-time password generated by a mobile phone, a hacker would have to steal a user’s password and unlocked phone to impersonate the user and gain access to their account. Requiring multiple factors for authentication therefore provides a stronger assurance that the person authenticating is the legitimate account owner.
Authorization policy may require multi-factor authentication for certain situations. It may be required at all times to access sensitive content such as administrative access to production cloud servers. In other situations, multi-factor authentication may only be required if an unusual situation is detected, such as a user attempting access from a new device or an atypical geographic location. Some enterprise environments may require multi-factor authentication for remote access or even in the office for more sensitive resources.
The selection of authentication mechanisms for a solution should take into account the sensitivity of the application and data involved as well as the usability of the solution because users may try to circumvent mechanisms that are too onerous or deemed overkill for a particular situation. Section 6 and specifically Section 6.2 of NIST publication 800-63-3 shows one example of how to approach the selection of an appropriate authenticator assurance level for a deployment.ii (NIST Special Publication 800-63Biii has the accompanying list of types of authentication for each authentication assurance level.)
Step-Up Authentication
When a user authenticates, an authenticated session is created with a certain level of authentication assurance that the user is the legitimate owner of the account. For example, if a user logs in with a static password, there is some chance the password was stolen and the account is being used by an imposter, so the user’s session might be considered at “level one” in terms of authentication assurance. If a user subsequently authenticates with a stronger form of authentication such as a one-time password generated on their mobile phone, the confidence that the user logging in is the legitimate account owner is much higher because it would be harder for someone to impersonate the user when their phone is required for authentication. After authenticating with the one-time password, the user’s session might then be considered at “level two” for authentication assurance. (Our choice of levels and names is an arbitrary example for purposes of illustration.) Step-up authentication is the process of authenticating with a stronger form of authentication in order to elevate the authentication assurance level of an existing authentication session.
Authorization policy may require authentication sessions to be at a specific authentication assurance level in order for a user to access resources or execute transactions that involve more risk. Applications with features that vary in sensitivity can use step-up authentication to require stronger authentication for more sensitive transactions. For example, a user might be able to browse a retail web site anonymously, but have to elevate their session by authenticating with a password to access previously stored address information for a purchase delivery. In an enterprise, a manager might be able to access the accounts payable system with a password to run reports, but then have to step up her session by authenticating with a one-time password in order to approve a payment for a large amount. Step-up authentication facilitates a model where the strength of the authentication mechanism required for a situation is commensurate with the risk inherent in the protected resources involved.
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, it may support shorter session timeouts for elevated sessions which provide access to more sensitive resources. Shorter session timeouts for more privileged sessions would 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. 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.
SAML 2.0
A SAML 2.0 authentication request can specify an application’s desired authentication context class using the <RequestedAuthnContext> element. A SAML 2.0 authentication response will show the authentication context class used to authenticate a user in the <AuthnContext> element of the authentication assertion, if the identity provider provides this information. The application (service provider) and identity provider must establish in advance the definitions for different authentication context classes. The document “Authentication Context for the OASIS Security Assertion Markup Language (SAML) V2.0”v lists several predefined authentication context classes which may be used.
OIDC
acr_values – Authentication context class reference
acr – Authentication context class reference, an identifier for an authentication context class
amr – Authentication methods reference, the identifiers for one or more methods used to authenticate a user
The application and OpenID Provider must establish the values and meaning for acr and amr values used. At the time of writing, there are draft specifications for standard values for these claims. The draft specification for OpenID Connect Extended Authentication Profile (EAP) ACR Values 1.0vi lists acr values, and the draft specification for Authentication Method Reference Valuesvii lists proposed amr values.
Step-Down Authentication
To align with the security principle of “least privilege,” one 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 a few deployment considerations worth mentioning. 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. Evaluating authentication devices for their durability, and battery life if applicable, is helpful 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 relatively weak form of authentication, whereas the use of one-time passwords generated on a device or multi-factor cryptographic authentication devices involves what are considered stronger forms. 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.0 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. It is important to terminate higher-level sessions in a timely manner via shorter session timeouts or logout, and conveniently, logout happens to be the topic of the next chapter.
Key Points
Static passwords are considered a weak form of authentication.
The compromise of a static password may not be noticed until damage is done.
It is harder for remote hackers to impersonate a user when authentication requires physical devices in the user’s possession.
Multi-factor authentication relies on multiple factors, such as something you know, something you have, and/or something you are.
Step-up authentication involves authenticating with a stronger form of authentication to elevate the authentication assurance level of a session.
Both SAML 2.0 and OIDC allow an application to request an identity provider use a specified authentication context class when authenticating users.
To support the principle of least privilege, it may be desirable to have shorter session timeouts for elevated sessions required to access sensitive resources.
Notes
- i.
- ii.
- iii.
- iv.
- v.
- vi.
- vii.