Identity & Authentication
Who are you? Credentials, password storage, credential stuffing, MFA, passkeys — and one login followed all the way from a browser to a database row.
Every lesson below identifies the asset, attacker capability and boundary before naming the vulnerability. Controls are split into prevention, detection and recovery; residual risk is explicit.
Authentication answers "who are you?"; authorization answers "what are you allowed to do?" — and the overwhelming majority of real access-control bugs are systems that did the first one correctly and skipped the second.
Authentication is not a login form: it is registration, credential storage, login, second factors, session establishment, re-authentication, recovery, device management and revocation — and attackers reliably target the least-defended stage, which is almost always recovery.
One login traced end to end at four zoom levels — browser to TLS to password verification to session to cookie to the authorized read — naming at every stage what is sent, what boundary is crossed, what must be protected, and what an attacker would try.
The database should never contain the password, and it should not contain a fast hash of the password either — because the entire threat model is what an attacker does with a copy of the table.
Offline guessing against a stolen table, online credential stuffing with passwords from other breaches, and targeted attempts against one account — three different attacks with three different defenses, only one of which is the hash function.
Requiring a second, independent kind of evidence — something you have or something you are, alongside something you know — with the honest ranking of which factors resist phishing and which merely resist password reuse.
Public-key authentication in the browser: the device keeps a private key, the server stores only the public key, and the signature is bound to the origin — which removes the shared secret and makes relayed credentials worthless.