P54 · Authentication & Kerberos

A login form is the most-attacked piece of code most applications own, and it is usually the piece written earliest, by whoever was available, against a tutorial. This pillar rebuilds it properly. Not as a checklist of best practices, but as a series of decisions with visible consequences: store the password this way and a stolen database is a catastrophe, store it that way and it is a bad week; compare the reset token like this and an attacker learns it one character at a time.

The first movement is the credential itself — deliberately slow hashing so that a leaked table resists offline cracking, rate limiting that makes online guessing pointless, second factors and the specific ways each of them fails, and the account-recovery flow that is so frequently the real front door while everyone stares at the password field. The second is what happens after the proof succeeds, because HTTP forgets you immediately: a cookie carrying a session id, with httpOnly, Secure and SameSite each stopping a named attack, versus a stateless token that scales beautifully and is much harder to revoke — a trade-off you will make explicitly rather than inherit. The third is Kerberos, which answers the same question at enterprise scale by removing the password from the wire entirely: a ticket-granting ticket from a KDC, time-bounded and sealed service tickets, authenticators that defeat replay, and the SPNs, keytabs and delegation you meet the moment this touches a real domain.