Authentication and passwords
Stolen credentials are the most common way into an organization. Learn how passwords should be stored — from plaintext to salted, slow hashes — how long guessing really takes, and why multi-factor authentication and passkeys change the game.
In this lecture you will
- Explain how passwords should and should not be stored
- Explain salts and why slow, memory-hard hashes such as Argon2 and bcrypt are used
- Estimate password strength from length and character set, and understand its limits
- Compare multi-factor methods, including phishing-resistant passkeys
A large share of breaches begin with stolen or guessed credentials. Attackers don’t need to break encryption if they can simply log in. This lecture covers the two halves of the problem: how a system should store passwords, and how it should authenticate users so that a password alone isn’t enough.
How passwords should be stored
Suppose your user database leaks — a misconfigured backup, a SQL injection, an insider. What the attacker gets depends entirely on how passwords were stored. Step through the evolution:
- PlaintextPasswords stored as typed. A single leak exposes every account — and because people reuse passwords, their email and bank accounts too.
- Fast hashStoring SHA-256(password) hides the text, but identical passwords give identical hashes, and GPUs can test billions of guesses per second. Common passwords fall instantly.
- Add a saltA unique random salt per user is combined with the password before hashing. Identical passwords now look different, and precomputed tables become useless — but guessing is still fast.
- Slow, memory-hard hashAlgorithms such as Argon2id, bcrypt and scrypt are deliberately expensive: tens of milliseconds and lots of memory per guess. A login barely notices; an attacker’s rate collapses.
- Add a second factorWith multi-factor authentication, even a cracked or phished password isn’t enough to get in.
In practice you don’t implement this yourself: use your framework’s password-hashing function or an identity provider, with Argon2id or bcrypt and current recommended cost settings.
How long does guessing take?
Strength comes from the number of possibilities an attacker must try. Adjust length and character set to see how the numbers move — and how much the storage method matters.
Two lessons stand out. Length beats complexity: each extra character multiplies the work. And storage matters as much as the password: the same password survives vastly longer when hashed with Argon2 or bcrypt.
Multi-factor authentication
A second factor combines something you know with something you have or something you are. They are not equally strong:
- SMS codes
- Much better than nothing, but vulnerable to SIM-swap fraud and to phishing pages that relay the code in real time.
- Authenticator apps (TOTP)
- Codes generated on the user’s phone. Stronger than SMS, but a convincing phishing page can still capture and replay them.
- Push approvals
- Convenient, but attackers exploit “MFA fatigue” by sending approval requests until a tired user taps yes. Number matching helps.
- Passkeys and security keys (FIDO2)
- Public-key credentials bound to the real website’s domain. Nothing reusable can be phished, and there is no shared secret on the server to steal.
An authenticator app is less magical than it looks. Watch one compute its codes:
Computed live in your browser with the demo secret from the standard’s test vectors (RFC 6238). The app and the server share the secret once, at enrolment; after that, the current time is the only other input.
That design has a weakness: a code works for anyone who has it within its short window. Compare a relaying phishing site against a passkey:
- A perfect copyA phishing email leads Asha to acme-login.co, a pixel-perfect copy of the sign-in page. Behind it, the attacker’s server talks to the real site in parallel.
- The password is relayedAsha types her password; the fake page passes it straight to the real site, which now asks for the second factor.
- So is the codeHer one-time code reaches the real site within seconds, inside its validity window. The attacker receives the session cookie and is signed in as Asha.
- A passkey insteadWith a passkey, the browser checks which site is asking. Asha’s passkey belongs to acme.com, so on acme-login.co there is simply nothing to offer.
- Why it holdsThe domain check is done by the browser, not by a tired human reading an address bar, and the server stores only a public key — nothing reusable to steal.
For staff accounts — especially administrators, finance and anyone with access to production — phishing-resistant MFA is one of the most effective security investments a company can make.
Protect the whole login flow
- Rate limiting and lockouts slow online guessing and credential-stuffing attacks.
- Breached-password checks block passwords already published in earlier leaks.
- Secure account recovery — reset flows are often the weakest link (recall the threat model in lecture 1).
- Alerts on new devices, password changes and disabled MFA give users and security teams a chance to react.
- Single sign-on through an identity provider concentrates these protections in one well-maintained place instead of every application.
That completes the security foundations module: how attackers think, how layers stop them, and how cryptography and authentication protect data and accounts. Module 2 turns to specific attacks — the OWASP Top 10, injection, phishing and ransomware — and how to defend against each.
Key takeaways
- Never store passwords in plaintext or with fast hashes; use a unique salt and a slow, memory-hard algorithm such as Argon2id or bcrypt.
- Length matters more than complexity rules, and human-chosen passwords are far weaker than their length suggests.
- Multi-factor authentication stops most credential attacks; passkeys and security keys also resist phishing.
- Protect the whole flow — rate limiting, breach checks, secure resets and alerting — not just storage.
Check your understanding
3 questions · answers explainedQ1Why is SHA-256 alone a poor choice for storing passwords?
Q2What does a salt protect against?
Q3Which factor is resistant to phishing — a fake login page can’t capture and replay it?