padosoft-auth-hardeninglisted

# Authentication hardening The controls below are the ones that are typically *present and ineffective*: a limiter with the wrong key, a lockout event nothing emits, a session lifetime that is a sliding window, a revocation that covers one door out of three. **The rule: identity is a set of doors, and hardening means none of them disagrees with the others.** --- ## 1. Rate limiting needs two keys, not one ```text per address only → distributed credential stuffing walks through per account only → N accounts get swept in parallel from one machine both → the attack has to be both slow and narrow ``` - Key the per-account limit on a **hash of the normalised identifier**, never the address itself: a limiter backed by a shared cache otherwise stores your users' email addresses in plaintext, in a second system, for ever. - Put the client address **into** the per-account key as well, or an attacker can lock a real customer out of their own account at will. Denial of service against a named user is a cheap attack. - **Limit the reset and the contact forms too.** They send mail on somebody else's behalf. - **Check that a lockout actually emits an event.** Many frameworks only emit it from their own built-in throttling helper; a hand-rolled limiter raises nothing, so the detection rule that counts lockouts can never fire and nobody notices that nothing is noticing. ## 2. Nothing may enumerate accounts The response must be identical whether or not the acc