Insecurity protocols: an overview of modern authentication

Insecurity protocols: an overview of modern authentication

Speakers: Eric Chiang

Conference: BSidesSF 2024

YouTube: https://www.youtube.com/watch?v=yX8hyMmoVMo

Overview

This talk, "Insecurity protocols: an overview of modern authentication," delivered by Eric Chiang at BSidesSF 2024, provides a comprehensive and often critical "whirlwind" tour of various authentication protocols, ranging from the widely adopted to the notoriously complex. Chiang, who works at Google and has a background in device identity and as a co-lead for the OAuth special interest group in Kubernetes, offers a candid assessment of each protocol's design, common pitfalls, and security implications. The presentation aims to highlight the inherent complexities and often overlooked vulnerabilities within these systems, emphasizing that perceived similarities between protocols can mask vast differences in their security posture and implementation difficulty.

The article delves into the technical intricacies of JSON Web Tokens (JWTs), OAuth 2, OpenID Connect, SAML, FIDO2, Passkeys, and Trusted Platform Modules (TPMs). Chiang's analysis is grounded in practical experience, pointing out specific vulnerabilities, design flaws, and common misuses that security engineers frequently encounter. The talk serves as a crucial resource for anyone involved in designing, implementing, or securing modern authentication systems, providing insights into why certain protocols gain a "bad rap" and others are considered robust, ultimately underscoring the critical importance of understanding the underlying mechanisms to build truly secure applications.

Background

▶ Watch: JWT 'alg: none' vulnerability explained (03:00)

The landscape of modern authentication is a complex tapestry woven from various protocols, each designed to solve specific problems but often introducing new challenges. The need for this overview stems from the ubiquitous nature of these protocols and the persistent security issues that arise from their misuse or flawed implementation. Eric Chiang's talk addresses this by dissecting the historical context and design philosophies behind several key authentication schemes.

The journey begins with JSON Web Tokens (JWTs), which, despite their widespread use, have garnered a "general sense of security engineers grumbling about how awful JWTs are." This reputation, as Chiang explains, largely originated about a decade ago with a critical vulnerability identified by Auth0. This flaw exploited how many JWT libraries validated signatures, allowing attackers to specify the alg: none header, effectively bypassing signature verification entirely. This incident highlighted a fundamental misunderstanding of JWTs as a cryptographic primitive rather than merely a signed document. Subsequent research has continued to expose issues, such as developers implementing their own RSA padding, underscoring that JWTs, despite their apparent simplicity, are still cryptography and demand rigorous treatment. The broader ecosystem of JWT-related specifications, like JSON Web Encryption (JWE) and various signature schemes, further complicates their correct application.

OAuth 2 emerged as a solution for delegated authorization, enabling users to grant third-party applications limited access to their resources without sharing their credentials. However, its initial iterations presented their own set of challenges. A significant problem was the lack of a standardized way for applications to retrieve basic user information (like username or email) across different identity providers (IdPs). Each IdP implemented its own proprietary API endpoints and data formats, forcing developers to write provider-specific code. This fragmentation led to the development of OpenID Connect (OIDC), an identity layer built on top of OAuth 2, specifically designed to standardize user information retrieval and provide a verifiable identity token.

The talk also touches upon SAML (Security Assertion Markup Language), an older, XML-based protocol often used in enterprise single sign-on (SSO) scenarios. SAML's complexity, particularly in its XML signature validation mechanisms, has historically made it a fertile ground for vulnerabilities. Chiang's strong criticism of SAML stems from its intricate specifications, which often lead to implementation errors and authentication bypasses, contrasting sharply with the relative simplicity and robustness of newer protocols.

Finally, the presentation moves to the cutting edge of authentication with FIDO2 and Passkeys, which aim to replace traditional passwords with hardware-backed or synced cryptographic credentials. These protocols address the inherent weaknesses of passwords, such as susceptibility to phishing and brute-force attacks. The underlying technology, including Trusted Platform Modules (TPMs), represents a shift towards hardware-rooted security, offering stronger assurances of device identity and integrity. The evolution from physical security keys to software-synced passkeys reflects an ongoing effort to balance robust security with enhanced user experience, though not without introducing new complexities and interoperability challenges.

Key Findings

▶ Watch: OAuth2 PKCE for public clients (SPAs, native apps) (09:00)

Eric Chiang's presentation meticulously dissects several modern authentication protocols, revealing critical insights into their design, vulnerabilities, and appropriate use cases. The overarching finding is that complexity is a strong predictor of insecurity; protocols that are difficult to implement correctly are far more likely to harbor vulnerabilities.

1. JSON Web Tokens (JWTs) are Misunderstood and Often Misused:

• JWTs are fundamentally signed documents, not a comprehensive security scheme or PKI infrastructure. Their accessibility often leads developers to implement custom, insecure cryptographic operations (e.g., RSA padding).
• The infamous alg: none vulnerability, which allowed signature bypass by declaring no algorithm, severely damaged JWT's reputation and highlights the dangers of relying on header values for security decisions before verification.
• JWTs are unsuitable for stateful sessions requiring immediate revocation, as their stateless nature makes revocation difficult without complex, often inefficient, out-of-band mechanisms.

1. OAuth 2 Has Matured, but Access Tokens Remain Dangerous:

• OAuth 2 has seen significant security improvements, notably the widespread adoption of Proof Key for Code Exchange (PKCE). PKCE effectively deprecates the less secure implicit flow, making OAuth 2 safer for public clients like single-page applications (SPAs) and native mobile apps by preventing code interception attacks.
• Despite these advancements, OAuth access tokens are still highly dangerous if compromised. They grant direct access to user resources, necessitating strict scope management by enterprise administrators to minimize potential damage from breaches.
• The existence of numerous, sometimes ill-conceived, additional RFCs for OAuth 2 underscores the need for careful evaluation; not all standardized extensions are good ideas.

1. OpenID Connect (OIDC) Standardizes Identity but Retains Nuances:

• OIDC successfully addresses the fragmentation of user information retrieval in OAuth 2 by providing a standardized identity layer. It defines standard scopes (e.g., openid, profile, email) and returns an ID token (a JWT) containing user claims.
• However, IdP-specific nuances persist. For example, Google's handling of non-Gmail accounts can lead to misinterpretations of organizational affiliation.
• A common misuse is treating the OIDC ID token as a general authentication mechanism outside the OIDC flow. When used this way (e.g., by DataBricks, HashiCorp Vault, Kubernetes), explicit JWT signature and claim validation is absolutely critical, as the original TLS protection of the OIDC flow is no longer present.

1. SAML is an Inherently Flawed and High-Risk Protocol:

• Chiang unequivocally labels SAML as "by far the worst commonly used industry cryptographic protocol." Its extreme complexity, particularly in XML signature validation, is a major source of vulnerabilities.
• Key complexities include: signatures being inside the signed object, the intricate and error-prone process of XML canonicalization, the convoluted nature of XML namespaces (inheritance, aliasing, attributes), and the ability to sign only sub-portions of a document, leading to valid but largely unsigned responses.
• This complexity frequently results in authentication bypasses across various SAML implementations, making it a protocol to avoid if possible.

1. FIDO2 is a Robust and Well-Reasoned Modern Authentication Standard:

• Comprising WebAuthn (the JavaScript API) and CTAP2 (the browser-to-key protocol), FIDO2 provides a strong, hardware-backed second factor.
• Its design is relatively simple and auditable, involving distinct registration and authentication phases with clear challenge-response mechanisms.
• A key innovation is the use of encrypted credential IDs, which often contain the private key encrypted by the security key itself. This allows security keys to be stateless and support an "unlimited" number of websites without storing a large number of private keys on the device.

1. Passkeys Evolve FIDO2 for Passwordless Login, but Face UX and Interoperability Hurdles:

• Passkeys are a software-based extension of FIDO2, designed to replace passwords as the primary authentication factor. They leverage the same underlying FIDO2 protocol.
• A significant change is the browser's omission of the client ID during passkey challenges, leading to a different user experience where the browser presents a list of available passkeys.
• Practical challenges include: limitations of resident keys on existing security hardware (e.g., some YubiKeys only store 24 keys without management interfaces), and interoperability issues across different device ecosystems (e.g., Chrome on macOS using iCloud keychain, preventing sync to Android). These issues hinder the "magical syncing" promise of passkeys.

1. Trusted Platform Modules (TPMs) Offer Powerful Hardware Attestation but are Incredibly Complex:

• TPMs provide crucial capabilities: linking keys to devices, attesting to device state (via PCRs and event logs), and guarding secrets based on that state.
• The process of remote attestation, involving signing PCRs and verifying against an event log, offers high assurance of device integrity.
• However, TPMs are "incredibly complex" to implement and verify correctly. Mistakes, such as relying on fields not part of the digest, are common. Few vendors fully expose or leverage TPM capabilities, making it difficult to obtain and verify PCR values.

In summary, Chiang's findings underscore the critical need for security professionals to deeply understand the protocols they deploy, to prioritize simplicity and well-vetted implementations, and to be acutely aware of the specific attack vectors and defensive measures associated with each authentication scheme.

Technical Deep Dive

▶ Watch: SAML's history of authentication bypasses (18:00)

The talk provides a detailed technical examination of several authentication protocols, highlighting their internal mechanisms, design choices, and inherent complexities.

JSON Web Tokens (JWTs)

A JWT is a compact, URL-safe means of representing claims to be transferred between two parties. It consists of three parts, separated by dots, and Base64url encoded:

1. Header: Contains metadata about the token, such as the alg (algorithm) used for signing and the typ (type) of token.
2. Payload: The "real meat and potatoes," containing claims about the entity (e.g., user ID, roles) and other metadata (iss for issuer, exp for expiration, sub for subject).
3. Signature: A cryptographic signature over the Base64url encoded header and payload, used to verify the token's integrity and authenticity.

Chiang clarifies that JWTs primarily define the structure of the payload claims, while the JSON Web Signature (JWS) specification defines the signature protocol. The notorious alg: none vulnerability arose because many libraries would read the alg from the header before verifying the signature. An attacker could set alg: none, and the library would then skip signature verification, accepting any payload. This, along with developers implementing custom RSA padding, demonstrates the danger of treating JWTs as simple data structures rather than cryptographic objects. The speaker also notes the existence of a broader ecosystem, including JSON Web Encryption (JWE) for encrypted JSON objects, and warns against "weird things like multiple signature schemes for JWTs."

OAuth 2

OAuth 2 is a delegation protocol, allowing a user (resource owner) to grant a third-party application (client) limited access to their resources on an identity provider (authorization server) without sharing their credentials. The typical flow involves:

1. The client redirects the user's browser to the identity provider (IdP), including its client_id and requested scope (e.g., read:email).
2. The IdP authenticates the user and prompts them to authorize the client's requested access.
3. If approved, the IdP redirects the user back to the client's pre-registered redirect_uri with an authorization code.
4. The client, on its backend, exchanges this code with the IdP's token endpoint, presenting its client_id and client_secret.
5. The IdP validates the code and client credentials, then issues an access_token (and optionally a refresh_token).
6. The client uses the access_token to make API calls to the IdP's resource server on behalf of the user.

Crucial security considerations include the state parameter, a random value generated by the client and included in the initial redirect, then verified upon callback. This protects against Cross-Site Request Forgery (CSRF) and other redirect-based attacks. For clients that cannot securely store a client_secret (e.g., single-page applications, native mobile apps), Proof Key for Code Exchange (PKCE) is used. PKCE involves the client generating a code_verifier (a random string) and a code_challenge (a hash of the verifier) for the initial request. When exchanging the code for a token, the client sends the code_verifier, which the IdP hashes and compares to the code_challenge. This ties the authorization request to the token exchange, preventing code interception. PKCE has effectively rendered the less secure "implicit flow" obsolete. Chiang stresses that access_tokens are "really, really dangerous" and scopes must be carefully restricted.

OpenID Connect (OIDC)

OIDC builds an identity layer on top of OAuth 2, standardizing how clients obtain basic user profile information. It addresses the problem of different IdPs having proprietary APIs for user data.

During an OIDC flow, in addition to an access_token, the IdP returns an ID token, which is a JWT. This ID token contains claims about the authenticated user, such as:

• sub: A unique identifier for the user.
• name, preferred_username, picture: From the profile scope.
• email, email_verified: From the email scope.

The openid scope explicitly indicates that OIDC is being used. OIDC also includes a discovery mechanism, allowing clients to fetch all necessary IdP endpoints and configuration from a single well-known URL.

Chiang points out that while OIDC standardizes identity, IdP-specific nuances still exist. For instance, Google's handling of non-Gmail accounts might lead to incorrect assumptions about organizational affiliation based solely on email domain. A significant issue arises when ID tokens (JWTs) are used for authentication outside the original OIDC flow (e.g., as API keys for DataBricks or Kubernetes). In such cases, the client must perform full JWT validation (signature, issuer, audience, expiration) because the TLS protection of the original OIDC communication is no longer present.

SAML (Security Assertion Markup Language)

SAML is an XML-based standard for exchanging authentication and authorization data between an identity provider and a service provider. Chiang expresses strong disdain for SAML, calling it "insane." The flow is similar to OAuth 2 but typically uses HTTP POST:

1. The service provider (client) initiates a request, often by redirecting the user to the IdP.
2. The IdP authenticates the user.
3. The IdP then immediately POSTs a SAML response (a signed XML document) back to the service provider. This response contains assertions about the user.

The core technical problem with SAML lies in its XML signature validation. Chiang highlights several complexities:

• Signature inside the signed object: The <Signature> element is often embedded within the XML document it purports to sign, which is counter-intuitive.
• XML Canonicalization: To verify the signature, the XML document must be transformed into a canonical form. This process is "super complicated," involving intricate rules for whitespace, attribute ordering, and namespace handling. Chiang gives an example from the spec that reads world.txt from disk, illustrating the potential for unexpected behavior.
• XML Namespaces: Namespaces are notoriously complex in XML, with inheritance, aliasing, default namespaces, and attribute namespaces, all of which SAML leverages, making parsing and validation extremely difficult.
• Partial Signing: SAML allows signing only portions of the document. A SAML response might appear unsigned, but specific assertions within it could be individually signed, making overall validation a nightmare.

These complexities, according to Chiang, are why "every SAML implementation I've ever worked with has had an auth bypass."

FIDO2 (WebAuthn & CTAP2)

FIDO2 is a set of open standards for passwordless authentication, leveraging public-key cryptography and hardware security keys. It comprises two main protocols:

• WebAuthn (Web Authentication API): A JavaScript API that allows web applications to interact with authenticators (security keys).
• CTAP2 (Client to Authenticator Protocol 2): Defines how browsers communicate with security keys.

The FIDO2 process has two phases:

1. Registration:

• The relying party (website) sends a challenge to the browser.
• The browser, via WebAuthn and CTAP2, instructs the security key to generate a new public/private key pair.
• The security key returns the public key and a credential ID to the relying party. The challenge is used to prevent replay attacks.
• A key innovation: for most security keys, the credential ID is an encrypted blob containing the private key. This allows the security key to be stateless, meaning it doesn't need to store thousands of private keys internally, yet can support an "unlimited" number of websites.

1. Authentication:

• The relying party sends a new challenge and the previously registered credential ID to the browser.
• The browser passes these to the security key.
• The security key decrypts the private key from the credential ID, signs the challenge, and returns the signature to the relying party for verification.

Chiang praises FIDO2 as "easily one of the best examples of actual modern authentication" due to its reasoned protocol and clear design.

Passkeys

Passkeys are a software-based evolution of FIDO2, designed to replace passwords entirely. They use the exact same FIDO2 protocol but aim to provide a more seamless user experience by syncing cryptographic credentials across devices (e.g., phone, laptop).

The key difference is that when a browser challenges a passkey, it does not provide the client ID. Instead, the browser presents a user interface listing available passkeys for the domain, allowing the user to select one.

However, Chiang highlights several challenges:

• Security keys make "really bad passkeys": Traditional hardware security keys often have limited storage for "resident keys" (keys stored on the device, necessary when no client ID is provided). Some YubiKeys, for example, only support 24 resident keys and lack management interfaces.
• Interoperability issues: The "magical syncing" promise of passkeys is often hindered by ecosystem fragmentation. For example, Chrome on macOS might use iCloud Keychain, which doesn't sync with Android phones, creating a disjointed experience.

Trusted Platform Modules (TPMs)

TPMs are secure cryptoprocessors that provide hardware-rooted security capabilities, acting as a "stand-in for all other hardware attestation." Their core capabilities include:

• Linking keys to devices: Keys generated or stored in a TPM are cryptographically bound to that specific hardware.
• Attesting to device state: TPMs can measure and report on the integrity of the device's boot process and software configuration.
• Guarding secrets: Secrets can be encrypted such that they are only decryptable if the device is in a specific, attested state.

TPMs store various types of keys (signing, encryption, application-specific). A crucial feature is that if one key is proven to be on a TPM, it can attest to the fact that other keys are also bound to that same TPM.

Device state tracking is managed through Platform Configuration Registers (PCRs), which are rolling hashes. During the boot process, each significant event (e.g., loading the bootloader, kernel, secure boot certificates) is hashed and extended into a PCR. This creates an immutable chain of trust. An event log records the details of these boot events.

Remote attestation involves challenging the TPM to sign the current state of its PCRs. The relying party can then replay the event log and verify the signed PCR values against the expected state, confirming the device's integrity remotely.

Chiang emphasizes that TPMs are "incredibly complex" to work with, noting that "there are actually very few vendors that seem to do this" correctly. Mistakes, such as relying on fields not included in the PCR digest, are common. Despite the complexity, hardware attestation is increasingly used for purposes like FIDO attestation (verifying a security key's batch), anti-spam (confirming a real Android device), and ensuring keys are hardware-backed.

Demo / Proof of Concept

▶ Watch: FIDO2 credential ID and stateless key design (20:00)

The talk "Insecurity protocols: an overview of modern authentication" is presented as a high-level "whirlwind" tour of various authentication protocols. While rich in technical detail and critical analysis, the speaker, Eric Chiang, does not describe or perform any live demonstrations or proof-of-concept implementations during the presentation. The content focuses on explaining the protocols, their vulnerabilities, and their implications through descriptive slides and verbal commentary.

Defensive Implications

▶ Watch: TPM PCRs and remote attestation (26:00)

Understanding the intricacies and vulnerabilities of modern authentication protocols is paramount for building robust defensive strategies. Eric Chiang's talk provides several actionable insights for security professionals:

• For JWTs:
• Use robust, well-vetted JWT libraries: Never attempt to implement custom cryptographic operations or validation logic. Rely on established libraries that have been thoroughly audited and protect against known vulnerabilities like alg: none.
• Understand their limitations: JWTs are signed documents, not a full security scheme. Do not use them for stateful sessions where immediate revocation is a requirement, as their stateless nature makes this challenging.
• Validate all claims: Always verify the issuer (iss), audience (aud), and expiration (exp) claims, in addition to the signature.

• For OAuth 2:
• Always implement PKCE: For all public clients (single-page applications, native mobile apps), PKCE is essential to prevent authorization code interception. This effectively deprecates the less secure implicit flow.
• Utilize the state parameter: Include a cryptographically random state parameter in all authorization requests and verify it upon callback to mitigate CSRF and other redirect-based attacks.
• Restrict scopes rigorously: Grant third-party applications only the absolute minimum necessary permissions (scopes) to limit the impact of a compromised access token.
• Be wary of phishing: Educate users about the dangers of granting access to suspicious applications, even if they mimic legitimate services.

• For OpenID Connect:
• Verify ID tokens explicitly: When an ID token (JWT) is used for authentication outside the direct OIDC flow (e.g., as an API key), it is crucial to perform full JWT validation, including signature, issuer, audience, and expiration. The original TLS protection of the OIDC flow is no longer guaranteed.
• Understand IdP-specific nuances: Do not assume that an email domain automatically implies organizational affiliation without explicit verification, especially with providers like Google that allow non-Gmail accounts.

• For SAML:
• Avoid if possible: Due to its extreme complexity in XML signature validation and historical susceptibility to authentication bypasses, SAML should be avoided in new implementations if more robust alternatives like OIDC are available.
• Rely on mature implementations: If SAML is unavoidable, use only extremely mature, well-audited, and widely adopted SAML libraries and products. Avoid custom implementations at all costs.
• Be vigilant for vulnerabilities: Stay informed about new SAML vulnerabilities and ensure patches are applied promptly.

• For FIDO2:
• Encourage adoption: FIDO2 (WebAuthn) provides a strong, phishing-resistant second factor. Encourage its use for critical accounts.
• Implement correctly: While simpler than SAML, ensure WebAuthn implementations follow best practices for challenge generation, credential storage, and signature verification.

• For Passkeys:
• Plan for interoperability: Be aware of the current limitations in passkey syncing across different device ecosystems (e.g., Apple, Google, Microsoft). Design authentication flows that account for these potential user experience hurdles.
• Consider resident key limitations: If using existing hardware security keys as passkeys, understand their limitations regarding resident key storage and management interfaces.
• Educate users: Explain the concept of passkeys as a password replacement and guide users through the registration and authentication process, especially given the evolving user experience.

• For Trusted Platform Modules (TPMs) and Hardware Attestation:
• Leverage for high assurance: Utilize TPMs and hardware attestation where strong guarantees of device identity and integrity are required, such as for enterprise device management, secure boot verification, or anti-spam measures.
• Seek expert guidance: TPMs are "incredibly complex." Rely on specialized libraries, frameworks, or expert consultation for correct implementation and verification of attestation, especially regarding PCRs and event logs.
• Push vendors for transparency: Advocate for vendors to provide better access and documentation for TPM capabilities, particularly the ability to read and verify PCR values and event logs.

In essence, defenders must prioritize simplicity, rely on well-vetted standards and implementations, and maintain a deep understanding of the specific security models and attack surfaces of each authentication protocol they deploy. The talk's central theme—that complexity breeds insecurity—should guide all defensive architectural decisions.

Key Takeaways

1. Complexity is a Predictor of Insecurity: Protocols with high inherent complexity, such as SAML and TPMs, are significantly more prone to implementation errors and vulnerabilities than simpler, well-reasoned protocols like FIDO2. Prioritize simplicity and clarity in authentication design.
2. JWTs are Signed Documents, Not a Security Scheme: While ubiquitous, JWTs are often misused. They are not a full PKI infrastructure and should not be treated as such. Always use robust, well-vetted libraries, avoid custom cryptographic implementations, and understand that JWTs are generally unsuitable for stateful sessions requiring immediate revocation.
3. OAuth 2 and OpenID Connect are Evolving Standards: OAuth 2 has matured with security enhancements like PKCE, which has effectively deprecated the implicit flow. OpenID Connect standardizes identity on top of OAuth 2. However, access tokens remain dangerous, and ID tokens (JWTs) require explicit, rigorous validation when used for authentication outside the direct OIDC flow.
4. SAML is a High-Risk Protocol: Due to its extreme complexity in XML signature validation, intricate canonicalization rules, and namespace handling, SAML is highly susceptible to authentication bypasses. It is considered "by far the worst commonly used industry cryptographic protocol" and should be avoided in new implementations if possible.
5. FIDO2 Offers Robust, Modern Authentication: Comprising WebAuthn and CTAP2, FIDO2 provides a well-reasoned, stateless, and hardware-backed mechanism for strong authentication. Its design allows security keys to support an "unlimited" number of websites, making it an excellent choice for multi-factor authentication.
6. Passkeys Aim for Passwordless, but Face Practical Hurdles: Built on the FIDO2 protocol, passkeys are designed to replace passwords. While promising, they introduce user experience challenges related to security key resident key limitations and significant interoperability issues across different device ecosystems, hindering seamless syncing.
7. Hardware Attestation with TPMs is Powerful but Complex: Trusted Platform Modules (TPMs) offer strong capabilities for linking keys to devices, attesting to device state, and guarding secrets. However, their implementation and verification are "incredibly complex," requiring deep expertise to avoid subtle errors that can compromise their security guarantees.

About the Speaker(s)

Eric Chiang is the speaker for "Insecurity protocols: an overview of modern authentication" at BSidesSF 2024. He works at Google, though his current role is not directly related to authentication. In the past, he has worked on areas such as device credential and device identity. Chiang is also known for maintaining "a lot of really random open source projects." His qualifications for delivering this talk are further underscored by his previous role as the co-lead for the OAuth special interest group in Kubernetes.