A Technical Deep Dive Into Passwordless Authentication (OPAQUE, WebAuthn, FIDO2)

Traditional authentication is broken. Relying on users to create, remember, and protect complex secrets is a model that fails at scale. Phishing, credential stuffing, and keylogging exploit the fundamental weakness of shared secrets: the human element. By 2026, relying solely on “strong passwords” is no longer a viable security strategy. We need architectural changes, not just stricter complexity rules.

True passwordless protocols like OPAQUE, WebAuthn, and FIDO2 offer a solution. These are not merely convenient login methods; they are cryptographic protocols designed to eliminate the shared secret vulnerability entirely. This article explores how they work, their technical implementation, and how to choose the right approach for your system.

The Failure of Shared Secrets

The core issue with passwords is that they are shared secrets. To verify your identity, you must share your secret with a server. If that server is compromised, your secret is stolen. If you are tricked into sharing that secret with a malicious site (phishing), your identity is stolen.

Attack vectors have evolved:

1. Phishing: Attackers act as legitimate entities to capture credentials.
2. Credential Stuffing: Automated bots test leaked credentials from one breach against other services.
3. Keylogging: Malware captures keystrokes before encryption occurs.

Even with best practices, the reliance on a static secret makes the system fragile. Protocols like OPAQUE and WebAuthn shift the model from “what you know” (a shared secret) to “proof that you know” or “proof of possession,” ensuring the server never holds material that can be used to impersonate the user.

“The only way to keep a secret is to never share it.” — Zero-Knowledge Principle

Defining Passwordless Authentication

“Passwordless” is often used as a marketing term for any flow that hides the password input. However, strictly speaking, it refers to systems where the server does not store or verify a user-generated password (shared secret).

Instead of sending a password to a server, the authentication happens locally or involves a cryptographic exchange where the server only verifies a proof.

Note that “Magic Links” and SMS OTPs are often marketed as passwordless but rely on transport layer security rather than cryptographic proof of identity. They often simply shift the single point of failure to the email provider or telecom vulnerabilities (SIM Swapping).

The Two Approaches: Software-Defined vs. Hardware-Backed

We can categorize robust passwordless solutions into two primary camps:

1. Cryptographic Passwordless (Software-First): Protocols like OPAQUE improve the password model itself. They allow users to use a password but ensure the server never sees it, not even during registration. This is ideal for universal access without specific hardware requirements.
2. Hardware-Based Passwordless (User-Centric): Standards like WebAuthn and FIDO2 utilize hardware authenticators (TPMs, YubiKeys, TouchID) to generate and store private keys. This offers the highest protection against phishing but requires compatible devices.

OPAQUE: The Gold Standard for Password-Based Auth

OPAQUE is an asymmetric Password-Authenticated Key Exchange (aPAKE) protocol that allows for extensive password authentication without the server ever learning the password. It addresses the main weakness of SRP (Secure Remote Password) and traditional hashing by utilizing an Oblivious Pseudo-Random Function (OPRF).

In an OPAQUE flow, the server acts as an oblivious storage for the user’s encrypted credentials. The server cannot brute-force the password offline because it never holds a verifier vulnerable to such attacks.

Forward Secrecy: OPAQUE ensures that even if a session key is compromised later, past sessions remain secure. This is a property often missing in simpler authentications.

Why not SRP? (The Pre-computation Attack)

Secure Remote Password (SRP), standardized in RFC 2945, was a breakthrough, but it has a subtle weakness: Verifier Leakage.

In SRP, the server stores a verifier $v = g^x \pmod N$. If an attacker steals the server database, they get $v$. While they can’t log in immediately, they can launch an offline dictionary attack. They can guess a password, compute $v_{guess}$, and check if it matches the stolen $v$.

• Pre-computation: Because SRP uses a standard salt, attackers can build “Rainbow Tables” if they know the parameters.
• The OPAQUE Advantage: OPAQUE’s OPRF key ($k$) acts as a secret salt that never leaves the server. An attacker with the database cannot verify a password guess because they don’t know $k$ to compute the OPRF output $H(password)^k$.
• The Halo Effect: This property essentially “hardens” low-entropy user passwords into high-entropy cryptographic keys.

The Mathematics of OPRF

At the heart of OPAQUE is the OPRF. An OPRF allows a client to compute $F(k, x)$ where $x$ is their input (password) and $k$ is the server’s key, using a simpler construction:

1. Blind: The client chooses a random “blinding factor” $r$ and maps the password to a point on an elliptic curve $H(Password)$. They send the blinded value $P$ to the server.
2. Evaluate: The server computes $Q = P^k$ using its secret key $k$ (which is never shared) and returns $Q$ to the client.
3. Unblind: The client computes the final result by removing the blinding factor: $Result = Q^{1/r}$.

This works because $(H(Password)^r)^k = (H(Password)^k)^r$. The commutativity of exponentiation allows the client to obtain $H(Password)^k$ without the server knowing $Password$, and without the client knowing $k$.

Why Ristretto255?

Modern OPAQUE implementations (like the one below) often use Ristretto255. This is not a curve itself but a construction on top of Curve25519.

• The Problem: Standard elliptic curves have “cofactors” and points of low order, which can introduce subtle vulnerabilities in complex protocols like PAKE.
• The Solution: Ristretto255 abstracts these details away, providing a prime-order group. It ensures that every valid 32-byte string maps to a valid group element, eliminating a specifically dangerous class of “invalid curve” attacks.

OPAQUE Implementation Example

Implementing OPAQUE requires a library that handles these heavy cryptographic primitives. Here is a registration flow using the @serenity-kit/opaque library, which internally uses Ristretto255 and SHA-512 for hashing.

1
import * as opaque from '@serenity-kit/opaque';
2

3
// Initialize the library (WebAssembly)
4
await opaque.ready;
5

6
// --- Client Side ---
7
const password = 'mySecurePassword';
8
// 1. Client starts registration (Blinding Step)
9
// Generates random factor 'r', helps compute P = H(pwd)^r
10
const { clientRegistrationState, registrationRequest } =
11
  opaque.client.startRegistration({ password });
12

13
// --- Server Side ---
14
// 2. Server generates a setup (Server Secret 'k')
15
const serverSetup = opaque.server.createSetup();
16
const userIdentifier = '[email protected]';
17

18
// 3. Server responds (Evaluation Step)
19
// Computes Q = P^k using the server's secret key
20
const { registrationResponse } = opaque.server.createRegistrationResponse({
21
  serverSetup,
22
  userIdentifier,
23
  registrationRequest,
24
    // The server never sees the raw password, only the blinded point.
25
});
26

27
// --- Client Side ---
28
// 4. Client finalizes (Unblinding & Encryption)
29
// Removes 'r' to get H(pwd)^k. Used to encrypt the user's private key.
30
const { registrationRecord } = opaque.client.finishRegistration({
31
  clientRegistrationState,
32
  registrationResponse,
33
  password,
34
});
35

36
// 5. Client sends 'registrationRecord' (The Envelope) to server

The Envelope

The registrationRecord is effectively a cryptographic envelope. It contains the user’s private keys (for the actual authentication phase) encrypted with the output of the OPRF.

• Encryption: Typically uses Argon2 or HKDF (HMAC-based Key Derivation Function) derived from the OPRF output to encrypt the payload.
• Security: Since the server doesn’t know the password, it can’t derive the key to open the envelope. It just stores it.

This model is resilient. Even if the server database is leaked, the attacker only gets the encrypted envelopes and the server’s private key. They still cannot perform offline dictionary attacks against the users’ passwords without interacting with the specific OPRF key, significantly raising the cost of attack.

WebAuthn & FIDO2: Phishing-Resistant Authentication

WebAuthn (part of the FIDO2 project) utilizes public-key cryptography to replace passwords. Unlike OPAQUE, which hardens passwords, WebAuthn replaces them with Asymmetric Key Pairs.

It relies on COSE (CBOR Object Signing and Encryption) algorithms for cryptographic operations.

Cryptographic Primitives: COSE Algorithms

When you register a passkey, the device and server negotiate an algorithm. Common identifiers include:

• ES256 (COSE -7): ECDSA with SHA-256 on the P-256 curve. The industry standard, supported by virtually all hardware.
• RS256 (COSE -257): RSA Signature with SHA-256. Older, slower, larger keys, but compatible with TPMs.
• EdDSA (COSE -8): Edwards-curve Digital Signature Algorithm, often using Ed25519. Faster and more secure than NIST curves, but less universal support.

WebAuthn Code Example

Here is a simplified example of creating a credential. Notice the pubKeyCredParams, which offers an ordered list of acceptable cryptographic suites.

1
// Register a new credential
2
const credential = await navigator.credentials.create({
3
  publicKey: {
4
    // Server-generated random challenge (prevents replay attacks)
5
    challenge: new Uint8Array([117, 61, 252, 231, 191, 241]),
6
    rp: {
7
      id: "example.com",
8
      name: "Example Corp"
9
    },
10
    user: {
11
      id: new Uint8Array([79, 252, 83, 72]),
12
      name: "[email protected]",
13
      displayName: "User Name",
14
    },
15
    // We offer ES256 (-7) and RS256 (-257)
16
    // The authenticator picks the best one it supports.
17
    pubKeyCredParams: [
18
      { type: "public-key", alg: -7 },   // ES256: NIST P-256 + SHA-256
19
      { type: "public-key", alg: -257 }, // RS256: RSA + SHA-256
20
    ],
21
    authenticatorSelection: {
22
      userVerification: "preferred",
23
      residentKey: "required", // Critical for "Passkey" behavior
24
    }
25
  },
26
});

The Assertion Flow (Login)

1. Challenge: The server sends a random nonce (to prevent Replay Attacks).
2. Signing:
   • The browser computes clientDataHash = SHA256(ClientDataJSON).
   • The authenticator computes the signature over AuthenticatorData || clientDataHash.
3. Verification: The server verifies the signature using the stored Public Key (e.g. using window.crypto.subtle.verify).

Because the signature covers the challenge (inside clientDataHash) and the origin (inside AuthenticatorData), it effectively binds the login to a specific session and a specific domain, neutralising phishing.

Security Model Comparison: OPAQUE vs. WebAuthn

Recommendation: OPAQUE is excellent for hardening existing password flows or providing a secure backup mechanism. WebAuthn is the superior choice for primary authentication due to its phishing resistance and user convenience.

Common Pitfalls in Passwordless Systems

Implementing these systems requires precision. Common mistakes include:

• Weak Account Recovery: Implementing secure WebAuthn but allowing account recovery via an insecure email link negates the security benefits. Attackers will simply target the recovery flow.
• Misunderstanding Resident Keys: “Resident keys” (now called Discoverable Credentials) allow for passwordless flows where the user doesn’t even need to type a username. Not enabling this flag creates a less seamless experience.
• Ignoring Cross-Device Friction: Hardware-bound keys (like a YubiKey) are secure but inconvenient if the user switches devices. Passkeys (synced FIDO2 credentials) solve this but introduce dependency on ecosystem providers like Apple or Google.

The Hybrid Approach

The most robust systems often employ a hybrid model. For instance, a system might use WebAuthn as the primary method for its speed and security, while using OPAQUE as a high-security fallback mechanism or for sensitive transactions that require explicit user intent beyond a biometric scan.

Conclusion

Passwordless authentication is not just about improving user experience; it is a fundamental shift in how we handle digital identity. By moving away from shared secrets and embracing protocols like OPAQUE and WebAuthn, we can build systems that are resilient by design. The technology is mature, the libraries are available, and the security benefits are undeniable. It is time to retire the password.

References & Further Reading

For those who want to verify the math or build their own implementations, here are the primary sources:

• OPAQUE Protocol:
  • IETF Draft: The OPAQUE Asymmetric PAKE Protocol
  • GitHub: Serenity-Kit OPAQUE Implementation
  • GitHub: OPAQUE IRTF Draft Working Area
• WebAuthn / FIDO2:
  • W3C Web Authentication Level 3
  • IANA COSE Algorithm Registry
  • MDN Web Docs: Web Authentication API
• Legacy Protocols:
  • RFC 2945: The SRP Authentication and Key Exchange System