secure-authlisted

# Secure Authentication Authentication is the front door to your system, and it is the single control attackers probe hardest. The goal of this skill is **not** to teach you to invent a clever scheme — it is to help you assemble well-understood primitives correctly, because almost every real-world breach in this area comes from a broken assembly of good parts, not from cracked cryptography. Heavy detail lives in `references/`; copy-paste material in `examples/`; a runnable policy check in `scripts/`. ## Mental model Three distinct questions get muddled constantly. Keep them separate: | Question | Concern | Wrong answer looks like | |---|---|---| | Who are you? | **Authentication** (login, password, MFA) | trusting a client-supplied `user_id` | | What may you do? | **Authorization** (roles, ownership, scopes) | checking auth but not ownership (IDOR) | | How do we remember you? | **Session management** (cookies/tokens) | long-lived tokens you can't revoke | A request can be perfectly *authenticated* and still be an attack if you skip *authorization*. The most common API vulnerability — Broken Object Level Authorization — is exactly this: a logged-in user reads `/accounts/124` when they only own `124`'s neighbor. Always check ownership server-side, never trust an identifier the client could change. ## 1. Password storage: slow hash, never plaintext The non-negotiable rule: **never store a recoverable password.** Store a one-way hash produced by a *deliberately slow* algor