Identity-Native Infrastructure Access Management

Chapter 4. Authentication

From the day that computers became a shared resource, authentication became a necessity. Authentication concerns itself with establishing a user’s identity, the important prerequisite for authorization (which is covered in Chapter 5).

In 1961, the MIT Compatible Time-Sharing System (CTSS) required operators to log in with credentials to prevent them from using more resources than their quotas allowed. Although computing environments themselves, mainly located in universities, could be trusted, it became clear that tenants often couldn’t be. For over 60 years, computer authentication has been central to the management of resources.

For many years, perimeter authentication used to be the only line of defense against insecure practices, human error, and inappropriate access. Even organizations that were aware of the need for authentication as a perimeter defense didn’t bother to add internal authentication to software applications on their own corporate networks. As discussed in Chapter 3, authentication into the “trusted network” used to be thought of as sufficient.

To their credit, most modern organizations today add some form of authentication to internal networks and software applications. The current challenges in authentication are to move away from vulnerable authentication schemes based on secrets, and to address scalability problems while confronting the question of whether a shiny new authentication method supports decade-old database servers and other legacy infrastructure.

The basic task of adding authentication to computing systems has become relatively easy as numerous open source authentication solutions and libraries have come into play. Authentication as a service (AaaS) providers like Auth0 even offer no-code authentication configurations via a web interface.

The challenge of authentication for infrastructure access, however, remains: to pick an authentication strategy that is robust, scalable and, most of all, resistant to human error. The security of even the best password-based authentication scheme is irrelevant if the user writes down their password on a sticky note attached to the desk. A USB device-based authentication system isn’t a viable alternative if the organization’s security policy forbids inserting USB drives into client machines.

Authentication must treat humans and machines the same. In a complex computing environment, resources can be accessed by engineers, CI/CD automation, custom microservices, and various other forms of machine-to-machine access. The same access control system must be used to enforce policy for different types of subjects. Authentication must be robust, unique, and scalable. Zero Trust means we don’t trust the network but use identity instead for access control. Authentication is the bedrock of this approach because it establishes identity.

This chapter discusses authentication factors and a few of the authentication schemes built from them. The typical enterprise relies more and more on multifactor authentication (MFA) to provide hardened security, and single sign-on (SSO) to scale. A combination of SSO and MFA that uses strong factors such as public keys or certificates can be both strong and scalable. In the end, true identity-based authentication, with a trustworthy identity proxy and a second authentication step, moves beyond existing authentication schemes.

The following section begins by examining methods for evaluating and comparing the effectiveness and practicality of three popular authentication factors.

Evaluating Authentication Methods

Three main criteria prove especially useful for measuring the effectiveness of authentication methods: robustness, ubiquity, and scalability. These criteria apply to both authentication factors such as passwords, and the authentication schemes that use these factors as building blocks.

Robustness

Robustness refers to how well an authentication factor resists being broken. The resistance can be further classified into two properties:

• Resistance to brute-force attacks

• Resistance to human error

Brute-force attacks become easier every day. Modern computing processors are powerful enough to crack weak passwords in seconds. As of this writing, a pair of NVIDIA RTX 4090 graphic cards was benchmarked to crack 8-digit passwords in under 48 minutes using hashcat.¹ Authentication schemes must be mathematically secure enough to withstand brute-force attacks that use the power of modern computing resources.

Where there are humans, there’s human error. We can be easily tricked into giving away credentials. Authentication schemes must help humans commit fewer errors and recover from human error when it occurs. This means making it easier for users to develop good habits and behaviors, rather than encouraging security shortcuts such as writing down passwords or keeping sessions open indefinitely.

Ubiquity

Ubiquity means being present everywhere, applicable to any environment, resource, and use case. A ubiquitous scheme authenticates both parties in a transaction, whether they are humans, machines, or applications. Such a scheme works in any environment, including on-premises, cloud or cloud native, IoT, and both private and public networks. Finally, ubiquitous authentication applies to any use case, including OS authentication, database authentication, web authentication, mobile authentication, and others.

Without ubiquity, fragmented authentication methods for various use cases create authentication silos, downgrading the user experience and leaving weak spots for attackers to exploit.

Scalability

The explosion of cloud computing has brought a galactic expansion of scale. Gone are the days when a text file containing a few password hashes can present even the appearance of sufficiency. Modern authentication schemes must scale unflaggingly in the face of unrelenting demand. There are three types of scalability, from worst to best:

Exponential

Doubling the number of parties more than doubles overhead.

Linear or horizontal

Doubling the number of parties doubles overhead.

Logarithmic

Doubling the number of parties less than doubles overhead.

Exponential scale blows the roof off the graph fairly quickly, making it impractical in even a modest enterprise. As the scale of enterprises and networks breaks new frontiers, it will become increasingly important to achieve logarithmic scalability.

The price for choosing poorly scalable authentication is high operational overhead, which creates incentives for insecure shortcuts such as shared credentials. Shared credentials make auditing and accountability impossible under the best circumstances and dramatically increase the blast radius in the case of a breach or attack. A scalable authentication method is indispensable to make every resource and every client unique and identifiable. A daunting but important antidote to this problem is Zero Trust access, which requires authentication for everything.

We can use the criteria of robustness, uniquity, and scalability as a framework for evaluating existing and novel approaches to authentication. This is important as people make decisions about how to balance the costs of different authentication methods against the risks of insufficient security. The next sections discuss the three most common building blocks of authentication schemes: secrets, public keys, and certificates.

Secret-Based Authentication

Secret-based authentication works by verifying possession of a previously shared credential negotiated between client and server. As we’ve discussed, secrets are just data—and like any data, they can be copied, lost, stolen, spoofed, or leaked. Nevertheless, passwords and other secrets are the most common tools for authentication. They are very easy to implement, and we’ve become accustomed to this method of authentication since the early days, in the middle of the 20th century. In the modern age, secrets have taken on other forms that are less obviously passwords. Session tokens, magic links sent by email, browser cookies, API keys, and other secret sequences of characters, at their heart, are all just passwords. It will come as no surprise to the reader that secrets have limited robustness, ubiquity, and scalability.

Secrets: Robustness

By themselves, secrets offer no security at all. Unless a secret is encrypted in transmission, it can’t remain a secret for long. It is not an overstatement to say that without encryption, password-based HTTP authentication is absolutely useless. Every password-based system must rely on the encrypted network layer. Meanwhile, it’s not unusual for internal applications to be set up on a LAN without TLS, leaving passwords vulnerable to man-in-the-middle (MITM) attacks by anyone who is able to sniff network packets.

Passwords are not very robust, regardless of the method of transmission or management. In an attempt to increase their robustness, secret-based authentication schemes often institute requirements such as password length, special characters, and a brisk password rotation schedule. This paradoxically decreases security by encouraging lazy behavior on the part of the user. When passwords are hard to remember because they’re long and full of special characters, users tend to write them down or store them in plain text. When passwords must be rotated frequently, users come up with cheats like adding sequential numbers to the end of a password so they can use it again and again.

A password manager improves things somewhat by automating away the friction that encourages bad behavior. Because they can autogenerate robust passwords (thus alleviating the vulnerability of easily guessable secrets and taking away the responsibility of remembering passwords), password managers encourage good behavior, making it far less likely that users will share passwords between sites or store them in places where they can be stolen. Still, a password manager has to store secrets somewhere, so there is still a vulnerability.

On the server side, secret-based authentication induces another challenge: How do you manage secrets securely? Even with encryption at rest, the attack vector merely shifts to another secret: the encryption key. Even if passwords weren’t vulnerable in these ways, the fact that there is no set of standards means that password schemes can be implemented insecurely.

Worse, secrets have a habit of getting around: there’s nothing preventing a naive programmer or a DevOps engineer from storing passwords in plain text in code or configuration or logging them as part of an error message into a log file.

When you have no choice, the recommended way of storing passwords on the infrastructure side with any degree of security is to throw them away and store only a hash for each one. Hashing means using a one-way function that makes it impossible to recover the original secret. When a user authenticates by submitting a password, a hash of the input can be compared to the stored hash. Using computationally expensive hashing functions and adding random data called salt to the hashing process can make it very difficult to discover the passwords themselves. Just the same, companies consider passwords a significant liability even when salted and hashed.

Secrets: Ubiquity

Secret-based authentication is popular because it’s easy to implement under any environment and use cases. Passwords authenticate users in web applications, mobile apps, internal networks, emails, and other places. In a nutshell, passwords can be implemented anywhere.

Secret-based authentication is a one-way street: it attempts to authenticate users but doesn’t concern itself with helping users authenticate a computing resource they’re connecting to. In other words, a user has no way of knowing if the resources they’re accessing are what they claim to be. Theoretically, this could be solved by making each user maintain their own list of resource credentials and requiring computing resources to authenticate back. But this creates the famous trust on first use (TOFU) problem: How can you trust a resource when connecting to it for the first time? Secrets alone can’t solve this problem.

The one-sided nature of secret-based authentication is what makes phishing attacks possible. If you can’t securely authenticate a resource when you access it, you can’t know if the resource is what it claims to be. Bad actors have become very good at disguising their spoofed web forms, servers, and other resources as the genuine article. In other words, though secrets appear ubiquitous because they are used everywhere, they really aren’t. You can’t use secrets to authenticate both parties in a transaction, because they don’t solve the TOFU problem.

Secrets: Scalability

Passwords and other secrets impose high overhead, starting with the problem of distribution. For a password to work, it must be shared ahead of time between two trusted parties. With P clients and R resources, there are potentially P x R passwords. Adding a resource requires generating and distributing P passwords. Likewise, adding a client requires generating and distributing R passwords. This means exponential scale to begin with, but that’s not all.

To make matters worse, password formats are not portable, because there are no standards for passwords. That means a password generation scheme that works for one resource might not work for others. In other words, it’s not just the passwords themselves that introduce overhead, but a growing number of mutually incompatible password generation and management schemes.

Overall, despite their apparent simplicity and convenience, secrets don’t evaluate well against any of our three criteria. 

Public Key Authentication

Public key authentication is based on asymmetric cryptography and works by verifying the possession of a private key using only cryptography challenges.

Each party has a private key that is never shared with anybody, and a public key that is derived from the private key. To establish trust, a client and a resource exchange each other’s public keys. Each party can use its private key to cryptographically verify a message signed with its public key by the other party. This process is safe even over an open, unencrypted network connection, because the private key is never exchanged.

For a quick overview on how public key authentication works, let’s review how you use it for accessing servers with the SSH protocol:

1. The client and the server each generate a pair of private and public keys.

2. The public key of the server must be shared with the client; it’s stored in the known_hosts file with the public keys of all trusted servers. The client’s public key is also stored on the server in the authorized_keys file with other trusted public keys.

3. During connection, the SSH handshake takes place. Among other things, the client and server send each other handshake data signed with their private keys and validated on each side using each party’s corresponding public keys.

Unlike secrets-based authentication, public key authentication is performed both ways, establishing trust for both a client and a server, without requiring a secure connection.

Public key authentication: Robustness

Public key authentication stands on the shoulders of giants: mathematically robust asymmetrical cryptography standards and implementations come from a rich history of innovations in cryptographic theory. When properly implemented, public key authentication is practically guaranteed to be secure, because it uses difficult problems that are not feasible to crack with modern computing resources. Public-key solutions include open source implementations such as GNU Privacy Guard (GPG), OpenSSL and others. The standards continue to evolve as new theories and attacks emerge, meaning that simply keeping up with industry practices ensures robustness. As long as we use recommended cipher suites and key sizes (at least 2,048 bits for RSA), we can be sure that our encryption is practically uncrackable with modern computing resources.

Public/private key pairs are immune to many forms of human error. For example, it’s not possible to choose a bad, insecure SSH key the way you can with a password. A properly configured public key authentication system will not accept keys that do not adhere to a specific standard that specifies the cipher algorithm and a bit length. The public key is public, so it doesn’t matter who knows it; the private key is a secret, making it subject to theft, sharing, copying, and other vulnerabilities common to other kinds of secrets—but at least it’s not likely to be copy-pasted into an email, or written on a sticky note on anyone’s desk, so the private key is still somewhat better than a password.

Public key authentication: Ubiquity

Public key authentication relies on every party (subject and object) having its own key pair, enabling each to authenticate the other.  For example, in SSH, servers can authenticate users, but users can authenticate servers too. Although public key authentication is not as simple as password-based authentication, it can be used to authenticate anything as long as the underlying client implementation supports key generation and storage.

Public key authentication: Scalability

Public key authentication offers more security when compared with passwords and all forms of secret-based authentication.  Public keys are also more scalable than passwords because they can be distributed in the open. Public keys are also insensitive to sharing or even loss: they are designed to be shared and regenerated.

But public key authentication still suffers from exponential scalability problems. Recall the SSH public key maintenance problem from “Certificates as Public Keys”. When an engineer joins a company, their public key must be uploaded to all the SSH servers in the scope of access. When that engineer leaves the company, their public key must be purged from the list of trusted keys on all servers. Similarly, when a new server comes online, its public key must be shared with everyone who needs secure access. This creates a lot of overhead. Every engineer keeps a list of public keys for all servers, and every machine needs to have a list of all engineers’ public keys. This means that public key authentication, while robust and ubiquitous, fails on scalability.

Certificate-Based Authentication

Certificate-based authentication is based on public key authentication, with one additional attribute: all public keys must be digitally signed by the CA. A certificate is a public key supplemented with metadata and digitally signed. Besides the digital signature, certificates also have built-in expiration dates and offer the ability to attach metadata that can express nuanced authorizations.

Certificates: Robustness

Certificates offer the same robustness as public-private key pairs, with additional protections. Every certificate has an expiration date that makes it obsolete and useless after a set period of time. Even if an attacker has the formidable computing resources to try cracking a certificate’s encryption with brute force, the expiration date limits the time available for the attack. Certificates are also revocable. If a certificate (or its owner) is compromised, it can be rendered inert. A certificate’s metadata can pin a certificate to the context of its usage, making it valid only when used from a specific IP address, for example. The metadata can also contain specific, often temporary authorizations, reducing the blast radius of damage in the event that all other protections fail.

The most robust security feature that certificate-based authentication brings to the table is the ability to attest to an identity. Public key authentication works very well, but it still fails to establish trust: How can you ensure that a client or server is who it claims to be? For example, let’s take the example of a known_hosts file for SSH. This file provides trustworthy identification of servers in the form of a list of server IP addresses and public keys in the following format:

192.168.1.12 ssh-ed25519 
AAAAC3NzaC1lZDI1NTE5AAAAIOqn+5px2hJsspKZtP7uIlqofFAbDA6WghZjbNPZKdPo

We know that it is relatively easy to change IP addresses; if a malicious server responds with an IP address that was previously assigned to a trusted server, the client might just connect the user to this malicious host. Fortunately, SSH is aware of this weakness and warns users when an IP or public key of a previously trusted server has changed.

There is an even better way to solve this issue using solutions like mutual TLS (mTLS). In fact, when certificate authentication is enabled, the SSH protocol relies on its own flavor of mTLS.

mTLS enables two-way authentication similar to public key authentication, but with one additional security measure: certificate verification. The client and server can trust each other based on certificates signed by a CA, rather than trusting spoofable data such as network addresses. Using mTLS, you can provide secure access to server fleets or IoT devices even when these objects are too numerous and elastic to keep an inventory of their network addresses. The broader TLS mechanism helps prevent phishing, brute force, credential stuffing, spoofing, and MITM attacks, and makes sure that API requests come from legitimate, authenticated users.

The mTLS communication works like this:

1. The client connects to the server.

2. The server presents its certificate signed by a mutually trusted CA.

3. The client verifies the server’s certificate using the CA’s public key and responds with its own certificate.

4. The server verifies the client’s certificate using the CA’s public key and grants access.

From this point on, the client and server exchange information over an encrypted connection.

Certificates are resilient against human error. They are difficult to misuse in the first place, because much of the work such as certificate generation, verification, rotation, and revocation is automated away by the standardized protocols that use them. In the event a private key is lost, shared, stolen, or otherwise compromised, the expiration date prevents the certificate from remaining a liability for long. The policies configured by the CA make it possible to centralize and fully automate the process of issuing certificates.

Certificates: Ubiquity

Like public keys, certificates can be used to authenticate both a client and a resource. They can be used on anything, anywhere, as long as the underlying client machine can present certificates during authentication. Fortunately, most computing infrastructure, servers, and services support authentication using certificates. Certificates are also well suited for automation and machine authentication as every step in certificate-based authentication can be automated securely. Further, the digital signature and expiry time help securely assign credentials to ephemeral computing resources, enabling ubiquitous authentication without the risk of long-lived credentials.

Certificates are highly portable and easy to automate because they are standardized. There are two main types of certificates in use today: SSH certificates and the X.509 standard. Tools that handle all the manual operation to manage certificate and CA life cycles make certificate-based authentication easier to scale elastically as required.

Certificates: Scalability

Certificates scale logarithmically: adding a client or resource doesn’t require additional configuration. Clients and resources don’t need to maintain lists of passwords or public keys to remember who is trusted. In a transaction, both parties need only verify both certificates against the CA’s public key. With certificate chaining, you can even use certificates to extend trust beyond a single CA, or even outside the organization.

Like asymmetric key pairs, certificates enable both authentication and encryption without relying on an encrypted, trusted environment. This means fewer cross-team dependencies and fewer teams to manage. Because certificates can include any needed metadata, they can express fine-grained permissions and authorizations, along with any other temporary or permanent information about a client or resource.

The highly scalable nature of certificate-based authentication has made them the basis for machine-to-machine trust on the internet. mTLS is the foundation for the secure software update systems used on mobile and desktop operating systems. Nearly every website uses HTTPS (HTTP over TLS, also known as SSL) connections to authenticate into client’s browsers.

Certificate-based authentication is the most robust, ubiquitous, and scalable authentication scheme available today. It is one of the pillars of identity-native infrastructure access. Certificates minimize human error, discourage secret sharing, minimize blast radius of a private key loss, and attach a client’s identity in the form of a rich metadata to every secure session.

These three factors and others can work together when combined into sophisticated authentication schemes. Multifactor authentication, for example, uses several factors to provide additional security.

Multifactor Authentication

By themselves, all authentication methods are vulnerable to human error. Even certificates, which have many advantages and features, must be issued to users and are vulnerable to phishing at that moment. One way to harden authentication is multifactor authentication (MFA), which means adding additional authentication steps based on independent factors.

The foundation of MFA is that knowledge or possession of one form of credential is not enough; you need several authentication factors: something you know, something you have, and, in case of identity-native access, something uniquely linked to physical you. The point is that no single factor is guaranteed to be secure, but by combining factors you can achieve very high levels of security.

Although implementing MFA enhances security significantly, some MFA solutions are less secure than others and may allow bad actors to bypass or defeat them. For example, SMS-based MFA is considered vulnerable as techniques such as SIM (subscriber identity module) swapping can allow access to OTP (one-time password) codes from a hijacked phone number. Yet SMS-based MFA is still more secure than single-factor authentication.

One method of MFA is generating OTPs using a hash-based message authentication code (HMAC), a technique that uses a hash function to symmetrically generate the OTP. A seed value is preshared between client and server, which when fitted to a HMAC function will create identical codes on both the client and server, without the need to transmit the codes over the network. HMAC-based OTPs (HOTPs) use a counter that updates on each authentication request. The HOTP remains valid until the next request. The counter is known as a “moving factor” because it changes from one authentication request to another.

Another OTP method uses a time-based one-time password (TOTP), a type of HOTP that uses time as the moving factor. Each TOTP remains valid for a duration called the timestep, which is usually 30 or 60 seconds. Unfortunately, these methods are susceptible to phishing. Although the window of compromise is much shorter in HMAC and TOTP-based MFA than in simple password-based authentication, users can still be tricked into giving away their OTP codes.

A better way to implement MFA is based on biometric factors. Biometric factors attempt to capture the “something you are” component of MFA by encoding aspects of your physical self—your face, fingerprint, or retina, for example. Biometric factors also provide proof of presence, asserting that the authenticating principle is physically present and that the credentials are not stolen and reused.

Single Sign-On

Single sign-on (SSO) allows users to authenticate once, then access various resources without further authentication. There are two main benefits of SSO:

• Improved user experience, avoiding the painful need for frequent authentication

• Reduced operational overhead, maintaining a single authentication system

SSO providers usually offer identity management and authentication in a unified solution. This makes SSO an easy solution; centralized authentication is convenient when identity is already consolidated. SSO is generally implemented as a database of all users plus the authentication scheme of your choice—hopefully, hardened with MFA. When a user requests access to a protected resource, the resource forwards the request to the SSO provider. Once the provider verifies authentication, the user is forwarded to the resource with a secure session token that provides access.

How SSO Works

The core idea of SSO is to authenticate users once and allow them to log in anywhere. There are three primary SSO methods: domain credentials, credential injection, and federated authentication.

SSO with domain credentials

One approach to SSO uses Lightweight Directory Access Protocol (LDAP), an open standard for accessing directories securely over a network, or the Microsoft Active Directory (AD) service, a directory service developed by Microsoft for Windows domain networks that is directed toward similar goals. In this scheme, the user has a single set of credentials to authenticate with servers and networks on the same domain. When the user makes a request, the application forwards the credentials to the LDAP or AD server for validation.

SSO with credential injection

Some implementations rely on credential injection, in which a user’s credentials are injected into a session to the resource as if the user had typed them. There are two main types of credential injection:

• Client-side credential injection, the method used by password managers, uses a browser plug-in to add credentials to username and password fields. 

• In-flight credential injection uses a proxy server or bastion host to add credentials directly to the authentication request.

In-flight credential injection is often used in enterprise privileged access management (PAM) systems. It works like this:

1. The IDP (identity provider) stores all credentials, including passwords, API tokens, and private keys.

2. When a client makes a request, the request is routed through a proxy server or bastion host.

3. The proxy server or bastion host retrieves credentials from the IDP’s secure credential vault, injects them into the request, and forwards the request to the application or server.

An advantage of in-flight credential injection is that the access control system can enforce credential life cycle management in the background and the credentials need not be shared with developers and engineers. But credential injection is a solution to a problem created by secrets in the first place. Where there are secrets, there is always a risk of them getting stolen.

SSO with federated authentication

What SSO does for a single domain, federated authentication does across multiple domains. An identity provider usually implements both SSO and federated authentication in a single solution, to provide a single sign-on experience within and across domains in the enterprise. Federated authentication stitches together identity management systems running on multiple domains to allow users to access resources with a single set of credentials. Identity providers have converged on standards such as SAML and OpenID Connect to enable authentication flows between different IDPs and federated authentication providers built by different companies. This makes federated authentication a keystone in retaining true representation of identity throughout the authentication process.

By dramatically reducing the operational overhead of authentication, SSO makes it easier to implement the Zero Trust access principles of authenticating all resources, and helps organizations move away from protecting only the perimeter.

Beyond Traditional SSO

While SSO helps solve authentication scaling problems, it is not without flaws. The fear of SSO becoming a single point of failure is not uncommon, and popular SSO providers have themselves fallen victim to infrastructure attacks. For this reason, some organizations employ a tiered SSO approach, where particularly security sensitive resources are protected by more than one SSO system.

The other problem with traditional SSO solutions is that they mostly focus only on HTTP protocol and web applications. A typical computing infrastructure uses numerous other protocols such as RDP, SSH, and numerous database protocols. Most traditional SSO solutions don’t support SSO authentication to these protocols, and thereby create bad user experience and operational overhead. Conversely, infrastructure-specific access platforms solve this problem by offering SSO for all common protocols in a modern cloud native infrastructure stack, tying together authentication-based practices.

Finally, most existing SSO systems aren’t identity native because they proxy the identity of a user with a token or cookie—a secret—that doesn’t carry identifying information with it. To implement identity-native authentication requires a signed certificate bound to the identity of a user or a machine.

Identity-Native Authentication

An identity-native authentication access system moves beyond secret-based traditional SSO, providing a proxy that faithfully represents identity in the digital realm. It unifies authentication for humans and machines across all common infrastructure protocols and uses certificates as a mechanism for carrying user and device identity. This effectively leads to a second layer of authentication. First, the user (or machine) presents credentials—ideally, multifactor—to obtain a signed certificate that proves identity for the session. That certificate then becomes the credential for resource access, likely in an SSO scheme.

An identity-native authentication system proposes a different authentication workflow than using a traditional SSO workflow. In an identity-native authentication system, instead of managing credentials centrally in an IdM database, users are supplied with web authentication (WebAuthn) compatible devices, procured by the organization where device certificates are signed by trusted CA.

SSO authentication then involves credentials that are managed entirely at the user’s end. This makes the SSO portal just a credential exchange and computation portal rather than a perimeter gateway. The following sections discuss a few important topics in the establishment, authentication, and preservation of digital identity.

Identity Proofing

In Chapter 2, we asserted that identity proofing was the foundation of an identity-native system (see “Identity and Access Management”). Identity proofing and authentication seem similar at first glance: both are used to verify identity. But there’s a difference between the two, especially in the context of identity-native access control.

Remember: an identity is a collection of physical attributes, and a credential is just data associated with an identity for verification purposes. Identity proofing, then, is the process of verifying and attesting physical attributes to grant a credential for a user to present during authentication. An authentication system uses sets of challenges to prove possession of credentials, verifying that each credential is signed by a trusted CA before granting access to protected resources.

Figure 4-1 shows how identity proofing and authentication work together. There are five steps involved:

1. The user has a set of credentials, such as driver license and birth certificate, to prove real-world identity.

2. Identity proofing verifies these credentials, usually as a part of a new employee onboarding. The same mechanism is applied to a device issued to an employee, registering its real-world credentials (TPM) with the access control system.

3. Once the user and device identities are established, the user can request a new credential (certificate) that is issued by a common trusted certificate authority (CA) that is a part of the access control system.

4. The user presents this credential to gain access to desired resources.

5. Before granting access, the authentication system uses various authentication challenges to verify possession of the credential and verifies that the credential is signed by a trusted CA.

Steps 2 and 3 involve a process called device attestation, discussed in the next section.

Figure 4-1. The steps in identity proofing and authentication

Device Attestation

Device attestation, also called device trust, means ensuring that the computers and other devices humans use to remotely access information are trusted. Only trustworthy devices are allowed to remotely access infrastructure. A modern implementation of device trust takes advantage of TPMs that are present on many modern laptops and virtually all smartphones. A TPM is like biometrics for computers because it gives each device a unique identity backed by hardware. Device attestation establishes trust as follows:

1. A device is enrolled into the access control system used by the organization. This creates an identity record for the device.

2. The device identity is associated with the identity of a person who owns or controls it.

3. Authentication uses the combination of these two identities (human and machine) to establish trust and issue a certificate that allows specific infrastructure access for a specified period of time.

Linking both identities to the physical attributes of a device (TPM) and a human (fingerprint) removes all secrets and eliminates human error from the authentication process.

On one hand, device attestation can be considered an advanced form of MFA. Because a laptop is something you own, it becomes just an authentication factor. A broader and more profound implication of device attestation is that authentication must be performed not only for humans, but also for machines. Device attestation is recommended on the server side too: servers must enroll into the access control system and be given unique identities to become trustworthy.

Device attestation offers additional benefits directly related to secure access. For example, it can ensure that only devices with up-to-date software are allowed to access infrastructure. Another important use of device attestation is as an authenticator for WebAuthn.

WebAuthn

WebAuthn is a project intended to standardize authentication with public-key cryptography and MFA. Typically, the user uses a TPM-supported device as authenticator. A private key is derived from a biometric factor, such as by using Touch ID, Face ID, etc. Then the user enrolls the WebAuthn device to the server. Only public keys are uploaded in this case. After enrollment, the device stores an asymmetric key pair. Authentication uses a signature generated from the private key.

Authenticating Machines

It is relatively easy to authenticate humans, as we have the cognitive ability to respond to authentication challenges. Machines, on the other hand, must be configured to respond to authentication challenges automatically. This requirement, often paired with static credentials (secrets), quickly increases the attack surface. CI/CD solutions in particular represent highly valuable attack targets, as they often operate at root-level privileges for production environments and contain “bags of secrets” to authenticate into everything.

Moving away from static credentials and assigning identity to machines in the form of signed certificates during the time of resource provisioning is one possible way to implement machine authentication. Amazon Web Services (AWS) uses a similar mechanism to issue instance identity documents to virtual machines. AWS digitally signs an identity document for each EC2 (AWS virtual computing server) instance, assigning a unique identity to each server. This identity document can then be used to authenticate AWS compute instances.

Similarly, infrastructure services such as CI/CD communicating over TLS have digitally signed identity data by default in the form of a certificate. Since SSH and HTTP/TLS are the basis for nearly any application protocol offering authentication and encryption, tunneling all connections through an identity-aware authenticating proxy makes it possible to easily implement machine authentication in one place.

The last puzzle piece is to securely and periodically rotate certificates. We can solve this issue by decoupling the authentication client and credential fetching process. An automated solution helps further by dynamically renewing the certificates of machines and services in the background, preventing the vulnerability that would result from assigning long-lasting credentials.

Preserving Identity Postauthentication

Most authentication systems aim to preserve identity in a network session after the authentication process. Commonly, client identity is stored as session data in the form of long URLs or browser cookies. These methods of preserving identity are nothing but secrets, vulnerable to cross-site scripting attacks. Another problem is that session data and cookies are not standardized across different resource types. This illustrates yet another reason why user identity should be stored in a certificate instead. A certificate can safely carry the user’s identity “on the wire” in a standardized format that is well understood by all resources. And, unlike other forms of session data, certificates expire automatically, which makes them more resistant to leakage.

Another important factor for preserving identity in a portable state is to use protocols that have built-in support for carrying signed authentication data over the network. Authentication Protocols such as SAML, OpenID Connect, Kerberos support certificates, and attestation, can be utilized to safely preserve and transfer authenticated data across various applications, networks, and systems.

In other words, the popular advice of “not rolling out your own encryption” applies to authentication as well. Use authentication implementations based on open standards such as SAML or OpenID Connect for SSO, which issues X.509 and SSH certificates.

Authentication is only half the battle. Once a user or machine is securely, unambiguously identified, and the identity carried faithfully by proxy into the digital realm, there remains the challenge of proper authorization.

¹ See hashcat documentation.