Why Are Authentication and Authorisation So Difficult?

Let’s say you’re tasked with selecting a strong authentication solution for your organisation. Where do you begin? This article is the first of a series that will explore authentication and authorisation technologies in the context of recent exploits and developing trends.

Most people assume passwords must be supported as a baseline since we’re so accustomed to using them. CIS has produced guidance on strong passwords. Users are expected to somehow memorise or store the plethora of passwords that they’ve collected. The problem is that passwords are vulnerable to credential theft attacks either against the user - e.g., phishing, keylogging - or by brute force after obtaining credentials en masse from a server.

Multi-factor authentication (MFA) solutions are often considered to provide a higher level of protection against attacks. There are many of these to choose from. MFA can be a one-time password designed for a proprietary product, biometrics, or hardware storing a private key. There are also solutions that strengthen security compared to passwords alone, but are not considered MFA, including risk-based and knowledge-based authentication. Risk-based authentication evaluates behaviours or the location of the user, while knowledge-based authentication asks questions of the user that include red herrings to aid in identity proofing. When selecting an MFA solution, you should evaluate whether or not credential theft is possible and the risk reduction provided by a particular type of authentication or a specific solution.

Now let’s say you’re tasked with selecting the authentication mechanisms an application should support. Where do you begin? You might survey related applications to determine what is supported, or survey your user base to determine if a particular multi-factor authentication (MFA) solution is predominant. There’s a wide range of possible underlying technologies that may be supported when you consider MFA.

Here’s a sample of authentication technologies and protocols you might consider when exploring MFA.

Authentication Technologies (for a list of resources mentioned in this table, see note at end of article)
Authentication Type	Description	Considerations	Example
Password	Password-based authentication, in which a user types a password that may be sent and stored using a hash and may be encrypted for transfer from the client to the server. User: enters password that matches the password stored on the server.	Passwords are subject to credential theft attacks from both the client and server side through any number of methods, including phishing and brute force. If passwords are in use, ensure the stored passwords are hashed using a salt, and consider either migrating to a password authentication key exchange (PAKE) or a stronger form of authentication that does not involve a password.	HTTP Basic
Password Authenticated Key Exchange (PAKE)	A password is used to help two parties agree on a shared key using public key cryptography, in which the information on the wire (between client and server) is not subject to a replay attack and there’s no stored database or file of hashed passwords. User: enters a password	If your solution needs a password, this is a solid alternative that minimizes credential theft to keylogging attacks.	To select a PAKE scheme, see the Crypto Forum Research Group (CFRG) evaluation information to ensure the PAKE meets the use case requirements.
One-Time Passwords (OTP) and HMAC-based One Time Passwords (HOTP)	A one-time code is generated for every authentication. Algorithms behind the code generation are typically unique to a vendor and may be delivered to an application, a hard token/authenticator, or via an SMS message sent to a phone. User: Enters a password plus enters a challenge response (e.g., PIN) that may be generated on an external device, within an app, or sent via a text message.	If SMS is used, OTP may be captured. It is possible to phish OTP codes from a number of available solutions, not just SMS. Solutions vary between implementations, vendors, or standards. Attacks have occurred against a few of these technologies, but no known attacks are still active today.	SecurIDDuoOkta
Public Key Infrastructure (PKI)	Public/Private key cryptography can be used to verify the user and the server. The private key is used to sign (an encryption operation) some data. The user (or server) holds and protects their private key so when it is used, you have a high assurance on who signed the data and it’s verified using the complementary private key. The process is more complex than that for public key infrastructure, which relies on a certificate hierarchy model and in some cases federation across PKI instances. “Planning for PKI”, by Russ Housley and Tim Polk, has a solid explanation on pages 39-41. User: May use a password, biometric, or other type of authentication to gain access to a protected private key for use to generate the authentication interaction. The private key may be stored in a system-protected keystore or on an external device (e.g., smart chip) typically connected via USB or a dedicated hardware interface.	Each user is issued one authentication key pair plus associated certificate that is provisioned for use with each application that accepts it as a credential. A revocation process must be in place to help support a “path validation process” (e.g., RFC 5280) which ensures that a user, their certificate, and associated keys are all okay prior to verifying the cryptography works as expected to validate the user. Overhead can be cumbersome. Use of federation across domains may be complicated. It offers a high-level of security if implemented securely.	Department of Defense (DoD) Common Access Card (CAC) is a smart chip solution using a PKCS #11 (Public-Key Cryptography Standards) interface. PKI may involve keys stored locally or externally in a keystore (e.g., PKCS #11). It may also be used for server only authentication to provide Transport Layer Security (TLS) encryption in addition to the described “mutual authentication” between end user and application.
W3C WebAuthn and Client to Authenticator Protocol (CTAP)	Uses a raw public/private key pair per user, per application. The user stores all of their private keys on a hardware-based authenticator or in a system-based cryptographic keystore. User: enters a password or authenticates to a hardware-based authenticator using another means such as a biometric to gain access to the individual private key needed.	Simplifies the application management for connecting user identity to credentials in that each application issues key pairs. WebAuthn has been integrated into web and mobile clients.Application integration may not yet be as strong.	WebAuthn and CTAP are standardised protocols. You might use any hardware-based authenticator that supports these protocols, such as Yubico and Feitian. For server or application integration, there are a number of libraries that support WebAuthn.
Risk-based Authentication	Risk-based authentication can include a wide range of information about a user or their system. This could include profiled behaviours of a user or their system, including access times and preferred application or browser used. User: enters password or another authentication type that is coupled with risk-based authentication solution. Password is the authentication mechanism and risk-based observations are intended to enhance security	Risk-based authentication is not considered two-factor authentication even though it is stronger than a password used alone.	If a password is used, you may be subject to credential theft or replay attacks. The risk-based information may be attacked more easily than two-factor solutions mentioned (e.g., PKI with a smart chip; WebAuthn with a Universal Two-Factor or U2F authenticator; or password with an OTP).

Once you’ve selected which type of authentication to support, you may also need to pick a specific implementation if it is not a standard. This potentially complicates the end user’s environment if it’s not a match for the other applications in use. This National Security Agency (NSA) guide categorizes specific MFA solutions into the evaluation criteria from the National Institute of Standards and Technology’s (NIST) 800-63 authentication documents and is a very helpful resource for understanding the strength of each solution. If you are less familiar with identity management and all it encompasses, the NIST documentation is an excellent resource to learn more about this complex set of technologies.

Why So Many Options?

Authentication technology has evolved for a number of reasons, from improving security to meeting specific use cases. This flood of technologies is difficult for someone new to the area who is tasked with selecting one or more existing authentication protocols to support. On top of that, you may need to support one or more authorisation protocols now that you have what’s needed to make an authentication assertion.

Authorisation tokens, such as Kerberos, SAML, or OAuth tokens, are predominantly used once authentication has occurred. There are additional options, but for simplicity, we’ll keep it to these very popular authorisation protocols. We’ll explore single sign-on, federation, and authorisation more deeply in future blogs.

How Can I Prevent Credential Theft Attacks?

It there’s an option to move away from authentication types that can be subject to credential theft and replay attacks, that would help reduce the possible impacts of phishing attacks. The multi-factor authentication types included in the table (PKI, WebAuthN, and OTP) meet that objective, and there are some differences to consider when selecting one or more for support in your organisation or for your product. The public/private key pair models of PKI and WebAuthn prevent credential theft and are stronger when your keystore is external to your device.

OTP solutions are very popular, and integration from a user standpoint has been simplified with the use of password stores tied to a user’s OTP solution. OTP helps prevent the successful replay of passwords even when they are in use, since the OTP code is also required. As mentioned in the table, OTP codes may be phished. Even with this in mind, OTP offers a significant improvement to your level of protection from a password alone.

PKI and WebAuthN prevent credential theft as the user’s private key encrypts data, providing a signature that demonstrates the user in possession of that key is the only one who could have signed (encrypted) the data. The process is more complex, but this basic explanation helps to illustrate why public/private key pairs provide a good solution to prevent credential theft. The key is never exposed when used on a hardware-based authenticator. A challenge or data is “signed” on the hardware-based authenticator and that signed data is unique for every authentication attempt. The user can be verified because the matching public key can be used to decrypt the data to verify the signature by comparing the challenge data and ensuring it matches the original (the challenge data is new for each authentication attempt). PKI can be difficult and cumbersome to deploy and requires significant management overhead if run at more than a basic assurance level. PKI is well integrated into web and other applications as the supporting encryption libraries have long contained support for this authentication type.

The need for new options that provide protection from credential theft was clear, as was easing management considerations with a public/private key solution. As such, a technology from W3C, called WebAuthN, evolved from a FIDO alliance standard and uses raw public/private key pairs for authentication. Another interesting aspect of WebAuthn is that individual key pairs are generated for every user and application. This reduces some of the infrastructure burden associated with PKI, while also preventing credential theft. Browser and mobile device support are strong for WebAuthN and server side support is increasing, but could pose an integration challenge for some applications. This is an interesting option since the key pair is individual to each user and application. The user device to store key pairs may be independent of the application as a result and the device manages which key pairs should be used for each application authentication. The server or application also manages each user credential individually as a result. A change to one application may not impact the other applications.

Authentication and Authorisation Series:

Authentication and authorisation are foundational to any security program as we’ve noted in the CIS Critical Security Controls v8, specifically in Controls 5, Account Management, and Control 6, Access Control Management. As noted in the previous blog on Prioritising Your Zero Trust Journey Using Controls v8, these controls address NIST SP 800-207 zero trust tenets, on protecting access to an individual enterprise resource granted on a per session basis (tenet 3) and the strict enforcement of dynamic authentication and authorisation for all resources (tenet 6).

This article is the beginning of a multi-part series that will explore authentication and authorisation technologies in the context of recent exploits as well as future direction. Authentication and authorisation are complex technologies, which in itself creates a hurdle for organisations looking to move to stronger authentication solutions. This series will attempt to break down the key questions and point to solid industry resources that ideally are vendor agnostic.

Resources from Authentication Technologies table:

This article was originally published over on the CIS blog.