Serving the Right Recipe for End-User Authentication

Serving the Right Recipe for End-User Authentication

Speakers: Philippe De Ryck, Founder, Pragmatic Web Security

Conference: LocoMocoSec

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

Overview

In this insightful LocoMocoSec talk, "Serving the Right Recipe for End-User Authentication," Philippe De Ryck, founder of Pragmatic Web Security, delves into the critical landscape of user authentication in modern web applications. De Ryck, leveraging a unique culinary metaphor, dissects various authentication "recipes," from the ubiquitous and problematic password to cutting-edge, key-based solutions. The talk aims to guide developers and security professionals toward more secure and user-friendly authentication mechanisms, acknowledging the persistent challenges of adoption and implementation.

De Ryck begins by establishing the current, often insecure, baseline of password authentication and systematically explores alternatives, evaluating their benefits, drawbacks, and suitability for different application sensitivities. He emphasizes the urgent need to move beyond shared-secret password models, which are inherently vulnerable to common attacks like credential stuffing and phishing. The core of his presentation champions Web Authentication (WebAuthn) as the future, offering a robust, browser-native, and phishing-resistant solution.

This discussion is crucial for anyone involved in building or securing web applications. As digital identities become increasingly central to our online lives, selecting the correct authentication strategy directly impacts user trust, data security, and regulatory compliance. De Ryck's practical, analytical approach, combined with concrete technical details and clear recommendations, provides a valuable roadmap for evolving authentication practices away from legacy vulnerabilities and towards a more secure digital future.

Background

▶ Watch: Introduction and talk structure overview (0:00)

The pervasive issue of weak and compromised user authentication forms the backdrop for De Ryck's talk. Despite decades of security advancements, password authentication remains the de facto standard for accessing web applications and APIs. This enduring reliance persists due to several perceived benefits: passwords are lightweight, conceptually easy for users to understand, and highly portable across various devices and platforms. A user can sign up on a laptop and log in on a phone with the same credentials, a convenience that has historically outweighed security concerns for many.

However, these benefits come with severe security drawbacks, which De Ryck highlights as the primary motivation for seeking alternatives. Passwords are shared secrets, making them susceptible to theft, brute-force attacks, and credential stuffing due to widespread user reuse. The speaker deliberately avoids a deep dive into password security best practices, acknowledging the extensive existing literature, and instead focuses on revolutionary alternatives. The fundamental problem, as De Ryck frames it, is the inherent insecurity of a mechanism where both the user and the server implicitly "know" or can derive the same secret. The journey throughout the talk is therefore an exploration of how to mitigate or eliminate this shared-secret paradigm.

Key Findings

▶ Watch: Magic links: simple passwordless authentication (6:00)

De Ryck systematically dismantles the reliance on traditional passwords and proposes a tiered approach to authentication, aligning security strength with application sensitivity:

1. Passwords are a Liability: Despite their ubiquity, passwords are the weakest link. They are prone to reuse, theft, and brute-force attacks, leading to "massive problems" like credential stuffing. De Ryck strongly recommends avoiding them "when possible" and moving away from them for all sensitive applications.
2. Magic Links for Non-Sensitive Applications: For applications where a breach would have "very low or almost no impact" (e.g., a recipe website), magic links (passwordless authentication via email/SMS) offer a simple, user-friendly, and password-free alternative. While better than passwords in some respects (less susceptible to phishing, no password to remember), their security relies entirely on the underlying communication channel (email/SMS), making them unsuitable for sensitive data.
3. Key-Based Authentication is the Strongest: Cryptographic public/private key pairs represent the "strongest authentication mechanism we have." This method eliminates shared secrets, making it immune to brute-force attacks and significantly harder to compromise. It relies on possession of a private key, typically stored securely on a device, rather than knowledge of a secret.
4. WebAuthn (Web Authentication) is the Future: The WebAuthn (FIDO2) specification is highlighted as the pinnacle of modern user authentication. It brings robust, key-based authentication natively to web browsers, leveraging hardware security keys (e.g., YubiKey), built-in device authenticators (e.g., Touch ID, Windows Hello, Android phones), and provides strong phishing protection through origin binding. Google's deployment of security keys, eliminating 98-100% of successful phishing attempts, serves as a testament to its effectiveness.
5. OpenID Connect (OIDC) for Centralized Authentication: OIDC is presented not as an authentication mechanism itself, but as an Authentication Protocol that allows applications to offload authentication to a central identity provider (IdP). This facilitates single sign-on (SSO) and simplifies managing user identities across multiple services. While powerful for enterprise and large-scale applications, the actual authentication mechanism still happens at the IdP, which could be anything from passwords to WebAuthn.
6. Adoption Challenges Remain: Despite the clear security advantages of modern solutions like WebAuthn, De Ryck acknowledges that widespread adoption, especially for non-employee users, is still low. The "biggest challenge" is securing "buy-in" and overcoming the effort required to transition from familiar, albeit insecure, password-based systems.

Technical Deep Dive

▶ Watch: Cryptographic key-based authentication concept (11:30)

De Ryck systematically breaks down each authentication "recipe," detailing its technical underpinnings and security characteristics.

Password Authentication: The Baseline

The talk starts with the password as the foundational, yet flawed, mechanism. Users transmit a username and plaintext password to a backend. The backend hashes the password (or should) and compares it against a stored hash. If they match, an authenticated state (e.g., a session cookie or token) is issued. While simple and portable, the plaintext transmission (even over TLS, it's plaintext to the server before hashing) and the shared-secret nature make it highly vulnerable to credential stuffing, brute-force attacks, and phishing.

Magic Links: Passwordless Simplicity

For non-sensitive applications, magic links offer a passwordless experience.

1. A user provides an identifier (e.g., email address, phone number).
2. The backend generates a one-time token embedded in a link.
3. This link is sent via email or SMS.
4. The user clicks the link, which authenticates them.

De Ryck notes that while you can build a custom token mechanism, the W3C Decentralized Identifier (DID) specification offers a structured format. To enhance security, services like Auth0 implement a requirement that the initiation of the flow and the clicking of the magic link must occur in the same browser, mitigating risks if the link is intercepted. The primary security drawback is reliance on the third-party security of email or SMS providers, making it unsuitable for highly sensitive applications due to risks like SIM swapping or text message previews.

Key-Based Authentication: The Cryptographic Core

The most robust approach centers on cryptographic public/private key pairs.

1. The user possesses a private key, kept secret and typically non-extractable.
2. The server stores the corresponding public key, which is openly shared.
3. During authentication, the client (browser/app) uses its private key to generate a digital signature over a server-provided challenge.
4. The server uses the stored public key to verify the signature. A successful verification proves the client possesses the private key without ever exposing it.

This mechanism relies on asymmetric cryptography (e.g., RSA or elliptic curve (EC) algorithms with SHA256 hashing). The verification function takes the data, the public key, and the signature, returning true or false. This mathematical link ensures that only the holder of the private key can produce a valid signature for a given challenge, eliminating shared secrets.

Mutual TLS (mTLS)

One application of key-based authentication is Mutual TLS (mTLS). While standard TLS authenticates the server to the client, mTLS extends this to authenticate the client to the server using client certificates.

• The client has a certificate containing its public key and uses its private key for signing.
• The server verifies this certificate against a trusted Certificate Authority.

De Ryck mentions Belgian electronic identity cards (eIDs) as a real-world example. However, mTLS is generally "painful to setup," difficult to manage for users, and lacks portability across devices, making it impractical for general user authentication.

Mobile App Key Storage

A more practical key-based approach involves dedicated mobile applications storing private keys, often secured by biometrics (e.g., fingerprint, face ID) or a PIN.

1. The user initiates login on a web app.
2. The backend sends a challenge and a push notification to the registered mobile app.
3. The user approves the request on their phone, which uses the securely stored private key (e.g., in Android StrongBox or iOS Keychain) to sign the challenge.
4. The signed challenge is sent back to the server for verification.

This leverages OS-level security features but requires users to install separate apps for each service, which is not scalable.

Web Authentication (WebAuthn / FIDO2): The Future Standard

WebAuthn is presented as the culmination of key-based authentication, bringing it natively to web browsers via a JavaScript API, Navigator.credentials. It leverages authenticators – hardware keys (like YubiKey), or built-in device capabilities (like Touch ID on macOS, Windows Hello, or Android phones).

Registration Flow:

1. User initiates signup on a website (e.g., locomosec.com).
2. The backend asks the browser to create a key, sending a JavaScript call (Navigator.credentials.create).
3. The browser prompts the user to interact with an authenticator.
4. The authenticator generates a private/public key pair, signs a challenge with the private key, and sends the public key and signed challenge back to the browser.
5. The browser forwards this to the server, which verifies the signature and stores the public key with the user's account.

Crucially, the browser includes the origin (e.g., https://locomosec.com) in this process, binding the key to the specific website. This origin binding is a powerful anti-phishing mechanism; a key registered for locomosec.com cannot be used on a phishing site like l0comosec.com.

The Navigator.credentials.create API call involves parameters like:

• rp (relying party): Identifies the backend (e.g., id: "locomosec.com").
• user: User details, especially id for server-side linking.
• pubKeyCredParams: Specifies cryptographic algorithms, e.g., -7 for elliptic curve public keys with SHA256.
• authenticatorSelection: Defines desired authenticator properties, e.g., authenticatorAttachment: "cross-platform" for portable keys (like YubiKey) or "platform" for device-bound keys (like Touch ID).

Authentication Flow:

1. User initiates login, providing an identifier (e.g., "Philip").
2. The backend retrieves identifiers for all public keys registered to "Philip" and sends them to the browser along with a new challenge via Navigator.credentials.get.
3. The browser prompts the user to interact with an available authenticator.
4. The authenticator signs the challenge with the appropriate private key.
5. The signed challenge goes back to the server for verification.

Again, origin binding ensures the authenticator only signs for the legitimate website.

OpenID Connect (OIDC): The Protocol

OIDC is an authentication protocol designed to offload authentication to a central identity provider (IdP).

1. A user attempts to log in to a relying party (application).
2. The relying party redirects the user to the IdP.
3. The IdP handles the actual authentication (using any mechanism: passwords, MFA, WebAuthn).
4. Upon successful authentication, the IdP returns an identity token (a JSON Web Token - JWT) to the relying party.
5. This JWT contains user information, most critically the sub (subject) claim, which is a unique, unchanging identifier for the user at the IdP. The relying party maps this sub to its internal user account.

OIDC is beneficial for single sign-on (SSO) and managing multiple applications. De Ryck clarifies that OIDC delegates authentication; it doesn't replace the underlying mechanism. The IdP itself must implement strong authentication. Regarding JWT security, De Ryck notes that while the specification can be "very open and very imprecise" leading to vulnerable implementations if done custom, OIDC's use of JWTs is "correctly" defined within the spec, and modern libraries generally handle the complex verification steps appropriately. He advises using decent libraries and having team members who understand JWT security challenges.

Demo / Proof of Concept

▶ Watch: OpenID Connect: Centralized authentication protocol (32:00)

Philippe De Ryck provided a live demonstration of WebAuthn registration and authentication, illustrating its practical implementation directly in a browser. He used the publicly available demo website webauthn.io to showcase the user experience.

During the registration process, De Ryck used his MacBook's built-in Touch ID sensor on the touch bar as the authenticator, opting for convenience over a physical USB security key. The demonstration showed:

1. The webauthn.io website prompting for registration.
2. The Brave browser displaying a native prompt: "Brave is trying to authenticate you to webauthn.io."
3. The user interacting with Touch ID (touching the sensor).
4. A subsequent prompt from the site asking if the user wanted to "share information about the authenticator" (e.g., its strength or type), which De Ryck allowed.

He then walked through the underlying JavaScript code, specifically the Navigator.credentials.create API call. He explained key parameters within the call:

• rp.id (relying party ID): Clearly identifies the website, e.g., "webauthn.io".
• user.id: A unique identifier for the user on the server side.
• pubKeyCredParams: Specifies the cryptographic algorithms to be used, such as -7, which refers to elliptic curve public keys with SHA256 for signing.
• authenticatorSelection.authenticatorAttachment: This parameter dictates the type of authenticator. De Ryck highlighted the difference between "cross-platform" (for portable devices like YubiKeys) and "platform" (for device-bound authenticators like Touch ID), noting his choice of Touch ID was a "platform" authenticator.

For the authentication phase, De Ryck explained that the process is similarly straightforward for the user. After providing an identifier, the website would again prompt for interaction with the registered authenticator. The Navigator.credentials.get API is used here, passing a list of potential credential IDs to the browser. The browser then handles the interaction with the authenticator (e.g., Touch ID), which signs the challenge, and the signed response is sent back to the server for verification. This seamless user experience, combined with the strong security guarantees, underscores WebAuthn's potential.

Defensive Implications

▶ Watch: Summary of authentication recipes and recommendations (36:30)

The talk offers a clear roadmap for improving authentication security, with distinct implications for defenders:

1. Prioritize Phasing Out Passwords: For any new application development, passwords should be avoided. For existing applications, a strategic plan to migrate away from password-only authentication is crucial. This involves educating users and providing viable, more secure alternatives.
2. Strategic Use of Magic Links: Implement magic links only for non-sensitive applications where the impact of a breach is minimal. To mitigate risks, implement additional checks like requiring the same browser for initiation and completion of the magic link flow (as demonstrated by Auth0). Be acutely aware of the security posture of the underlying email or SMS service and potential vulnerabilities like SIM swapping.
3. Embrace WebAuthn as the Primary Solution: Defenders should actively advocate for and implement WebAuthn for all sensitive applications. This leverages hardware-backed security, native OS features, and, most importantly, provides robust phishing protection through origin binding. This significantly reduces the attack surface compared to passwords. Plan for user onboarding and education, as it represents a "new workflow" for many.
4. Robust Account Recovery for Key-Based Systems: The strength of key-based authentication (especially WebAuthn) means losing authenticators can lock users out. Implement a secure account recovery strategy. This might involve requiring multiple authenticators (e.g., multiple YubiKeys), or for enterprise environments, a well-defined technical support process. Avoid reverting to insecure recovery methods (e.g., email-based password resets) that undermine the overall security of the system.
5. Leverage OpenID Connect Wisely: For large application portfolios or when centralizing identity management, OpenID Connect is invaluable. However, defenders must ensure that the chosen Identity Provider (IdP) itself employs strong authentication mechanisms (preferably WebAuthn or MFA). OIDC offloads authentication, but the IdP's security is paramount.
6. Prudent JWT Implementation: When using JSON Web Tokens (JWTs), especially outside of standard OIDC flows, prioritize using well-vetted, robust libraries for token creation and, critically, verification. Ensure development teams deeply understand the security challenges of JWTs, including algorithm confusion attacks and proper claim validation.
7. Consult OWASP ASVS: For comprehensive authentication requirements and best practices, De Ryck recommends the OWASP Application Security Verification Standard (ASVS). This standard provides a detailed checklist of controls to ensure secure authentication implementation.

Key Takeaways

• Passwords are a major security liability: They are easily compromised through reuse, theft, and brute-force, and should be avoided for sensitive applications.
• Magic links offer simplicity for low-risk scenarios: They provide a passwordless experience suitable for non-sensitive applications, but their security is tied to the underlying email or SMS channel.
• Key-based authentication is the strongest approach: Using public/private key pairs eliminates shared secrets, offering superior protection against common attacks.
• WebAuthn (FIDO2) is the future of web authentication: It provides browser-native, phishing-resistant, key-based authentication leveraging hardware keys and device biometrics, significantly enhancing security and user experience.
• OpenID Connect centralizes authentication, but doesn't replace it: OIDC is a powerful protocol for offloading authentication to an Identity Provider, enabling SSO, but the IdP must implement strong underlying authentication mechanisms.
• Adoption and recovery are key challenges: Transitioning to stronger authentication methods requires user education, buy-in, and robust account recovery processes to handle lost authenticators.

About the Speaker(s)

Philippe De Ryck is the founder of Pragmatic Web Security, a company dedicated to helping organizations build more secure applications through training and security advisory services. With a background that uniquely blends his passion for application security (AppSec) with a professional Chef's degree, De Ryck brings a distinctive perspective to his talks, often employing food-related metaphors to explain complex technical concepts. He is a recognized expert in web security, specializing in authentication, authorization, and secure development practices, and is committed to guiding the industry towards more robust and practical security solutions.