Thema: authentication
-
JSON Web Tokens: Was schiefgehen kann und die Antworten von RFC 8725
JWTs sind signierte Claims, keine verschlüsselten Geheimnisse; den Algorithmus gegen eine Positivliste prüfen, Aussteller, Zielgruppe und Ablauf verifizieren, Lebensdauern kurz halten, 'none' nie akzeptieren, und daran denken, dass sich ein zustandsloses Token ohne serverseitige Liste nicht widerrufen lässt.
-
Cookie-Attribute: Secure, HttpOnly, SameSite, Domain, Path und das Präfix __Host-
Jedes Set-Cookie-Attribut schränkt ein, wohin ein Cookie gesendet wird oder wer es lesen kann: Secure beschränkt es auf TLS, HttpOnly verbirgt es vor Skripten, SameSite=Strict/Lax/None regelt das seitenübergreifende Senden, Domain weitet die Auslieferung auf Subdomains aus (bei einem host-only-Cookie weglassen), Path ist keine Sicherheitsgrenze, und das Präfix __Host- lässt den Browser Secure, Path=/ und kein Domain erzwingen. Cookies isolieren nicht nach Port.
-
Passwort-Reset-Abläufe, die keine Konten oder Tokens preisgeben
Ein Reset-Ablauf ist ein zweiter Anmeldeweg und verdient dieselbe Sorgfalt: Jede Anfrage identisch beantworten, ein einmal verwendbares, ablaufendes, zufällig erzeugtes Token an die hinterlegte Adresse senden, den Link aus einem festen Origin statt aus dem Host-Header aufbauen, nichts am Konto ändern, bevor das Token vorgelegt wird, und am Ende die Nutzerin oder den Nutzer benachrichtigen und über die normale Anmeldung führen.
-
Konto-Enumeration in Login-, Registrierungs- und Reset-Formularen verhindern
Jeder Unterschied zwischen der Antwort für ein bestehendes und ein nicht bestehendes Konto (Nachrichtentext, HTTP-Status, Weiterleitung, Zeitverhalten) erlaubt es einer angreifenden Partei, eine Liste gültiger Nutzerinnen und Nutzer für einen Angriff aufzubauen. Dieselbe generische Nachricht und denselben Status zurückgeben, auf beiden Pfaden dieselbe Arbeit verrichten, die unterscheidende Information in eine E-Mail verlagern und drosseln, damit die verbleibenden Unterschiede nicht in grossem Massstab abgetastet werden können.
-
Speichern von Passwörtern und API-Schlüsseln
Passwörter werden nur als gesalzene, langsame Hashes gespeichert (Argon2id, scrypt, bcrypt); API-Schlüssel mit hoher Entropie können einen schnellen, geschlüsselten Hash verwenden; beide werden in konstanter Zeit verglichen und nach der Ausgabe nie protokolliert oder zurückgegeben.
-
Zeitbasierte Einmalpasswörter als zweiter Faktor
TOTP (RFC 6238) leitet aus einem gemeinsamen Geheimnis und dem aktuellen Zeitschritt einen kurzen Code ab; es schützt vor der Wiederverwendung von Passwörtern, aber nicht vor Echtzeit-Phishing, und braucht sichere Speicherung des Geheimnisses, Uhrentoleranz und Wiederherstellungscodes.
-
OAuth-2.0-Client-Credentials für Machine-to-Machine-Zugriff
Der Client-Credentials-Grant erlaubt es einem Dienst oder Agenten, mit eigener Client-ID und eigenem Secret ein Access Token zu erhalten, ohne einen Benutzer; Scope und Resource Indicators grenzen das Token ein, und das Secret muss wie ein Passwort behandelt werden: vom Server gehasht gespeichert und vom Client rotiert.
-
Verringern generische Anmelde- und Reset-Meldungen die Kontoübernahme messbar, wenn Breach-Korpora ohnehin schon verraten, welche Adressen existieren?
Offene Frage: Empfehlungen verlangen nicht unterscheidbare Antworten für existierende und nicht existierende Konten, zu realen Kosten bei der Benutzbarkeit; hat irgendein Dienst gemessen, ob Credential-Stuffing oder gezieltes Phishing gegen ihn zurückgingen, nachdem die Enumeration geschlossen wurde – wenn Angreifer bereits über E-Mail-Listen aus Breaches anderer Seiten verfügen?
-
Grundlagen des Session-Managements für Webanwendungen
Session-Identifikatoren müssen zufällig, lang, auf ein Cookie mit Secure/HttpOnly/SameSite begrenzt, bei der Anmeldung neu erzeugt, serverseitig befristet und widerrufbar sein; Zustand serverseitig oder in signierten Tokens mit kurzer Lebensdauer speichern.
-
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.
Maschinenlesbar: JSON