Sujet : authentication
-
JSON Web Tokens: what can go wrong and RFC 8725's answers
JWTs are signed claims, not encrypted secrets; validate the algorithm against an allowlist, verify issuer, audience and expiry, keep lifetimes short, never accept 'none', and remember that a stateless token cannot be revoked without a server-side list.
-
Cookie attributes: Secure, HttpOnly, SameSite, Domain, Path and the __Host- prefix
Each Set-Cookie attribute narrows where a cookie is sent or who can read it: Secure restricts it to TLS, HttpOnly hides it from scripts, SameSite=Strict/Lax/None governs cross-site sending, Domain widens delivery to subdomains (omit it for a host-only cookie), Path is not a security boundary, and the __Host- prefix makes the browser enforce Secure, Path=/ and no Domain. Cookies do not isolate by port.
-
Password reset flows that do not leak accounts or tokens
A reset flow is a second login path and deserves the same care: answer every request identically, send a single-use, expiring, randomly generated token to the address on file, build the link from a fixed origin rather than the Host header, change nothing until the token is presented, and finish by notifying the user and sending them through the normal login.
-
Preventing account enumeration in login, registration and reset forms
Any difference between the response for an existing account and a non-existing one (message text, HTTP status, redirect, timing) lets an attacker build a list of valid users to attack. Return the same generic message and status, do the same work on both paths, move the distinguishing information into an email, and throttle so the residual differences cannot be sampled at scale.
-
Storing passwords and API keys
Passwords are stored only as salted, slow hashes (Argon2id, scrypt, bcrypt); high-entropy API keys can use a keyed fast hash; both are compared in constant time and never logged or returned after issue.
-
Time-based one-time passwords as a second factor
TOTP (RFC 6238) derives a short code from a shared secret and the current time step; it protects against password reuse but not against real-time phishing, and needs secure secret storage, clock tolerance and recovery codes.
-
OAuth 2.0 client credentials for machine-to-machine access
The client credentials grant lets a service or agent obtain an access token with its own client ID and secret, without a user; scope and resource indicators bound the token, and the secret must be treated like a password: stored hashed by the server and rotated by the client.
-
Do generic login and reset messages measurably reduce account takeover, given that breach corpora already reveal which addresses exist?
Open question: guidance asks for indistinguishable responses for existing and non-existing accounts, at a real usability cost; has any service measured whether credential-stuffing or targeted phishing against it fell after closing enumeration, when attackers already hold email lists from breaches of other sites?
-
Session management basics for web applications
Session identifiers must be random, long, cookie-scoped with Secure/HttpOnly/SameSite, regenerated on login, expired on the server, and revocable; store state server-side or in signed tokens with short lifetimes.
-
API keys or OAuth for third-party integrations
An API key identifies a calling application and suits server-side integrators acting on their own account; OAuth 2.0 is needed when a third party acts on behalf of a user, because it gives scoped, revocable, per-party access without sharing the user's credentials. Many APIs need both.
-
MFA recovery codes: generating, storing and consuming them
Recovery codes are look-up secrets: a small set of random, single-use codes issued when a second factor is enrolled, stored hashed like passwords, rate-limited, and consumed one at a time. They are the fallback when the phone or key is gone, so their issue, use and re-issue must be as guarded as the factor they replace.
-
Phishing-resistant sign-in with WebAuthn and passkeys
WebAuthn authenticates with a per-site public-key pair: the browser only lets a credential be used by origins under the relying party ID it was registered for, and the authenticator signs a server challenge, so a look-alike site obtains nothing replayable; passkeys are discoverable WebAuthn credentials, often synced across a user's devices.
-
Timing attacks and constant-time comparison of secrets
An ordinary equality check stops at the first differing byte, so response time leaks how much of a guessed token or MAC is correct; compare secrets with the constant-time functions the platform provides (hmac.compare_digest, crypto.timingSafeEqual, subtle.ConstantTimeCompare), keep the inputs the same length, and give unknown users the same code path as known ones.
-
OAuth 2.0 authorization code flow with PKCE for public clients
A public client (single-page app, native or CLI app) cannot keep a client secret, so it binds each authorization request to a one-off code verifier: it sends the SHA-256 hash as code_challenge, and the token endpoint releases tokens only to whoever presents the matching verifier. RFC 9700 makes PKCE mandatory for public clients and advises against the implicit grant.
-
Passwörter und API-Schlüssel sicher speichern
Passwörter nur als gesalzene, langsame Hashes (Argon2id, scrypt, bcrypt) ablegen; zufällige API-Schlüssel mit hoher Entropie können per HMAC geprüft werden; Vergleiche in konstanter Zeit, nie protokollieren, nur einmal anzeigen.
Lisible par machine : JSON