Authentication security: passwords, MFA and login flows
You apply in code and in Burp how passwords should be stored, the disclosure and brute-force risks in the login flow and the correct set-up of MFA and passkeys.
Level 201 · 17 lessons · 15 practice labs
Lessons
Passwords
- Authentication versus authorisation: who you are and what you may do
- Storing passwords: bcrypt, scrypt, Argon2 and salt
- Password policy: length, breached-password lists and NIST guidance
- Finding a weak password hash in code and migrating it
- Short task: migrate MD5-stored passwords to Argon2 at login
The login flow
- Username enumeration: different error messages and response times
- Against brute force and credential stuffing: rate limits, lockout and CAPTCHA
- Login logic flaws: skipped steps and wrong conditions
- Building safe "remember me" tokens
- Account recovery: security questions, e-mail and help-desk risks
- Short task: prove and close username enumeration in the lab app with Burp
Multi-factor authentication
- Factors: something you know, have and are
- Implementing TOTP correctly: secret, clock drift and backup codes
- MFA flow flaws: a skippable second step and unlimited attempts
- Passkeys and WebAuthn: phishing-resistant sign-in
- Seeing login attacks in logs: failed-attempt patterns
- Capstone: harden a login flow end to end and retest it
Practice labs
- Plain-text passwords in the database: Show that passwords are stored in plain text in the lab database and change the sign-up code to hash them with Argon2.
- Migrate unsalted SHA-1 hashes: Write code that migrates passwords stored as unsalted SHA-1 to bcrypt as users log in and show the old hashes declining.
- Sign-up checks against a leaked password list: Add a leaked-password list check and a length rule to the sign-up form, remove the complexity rule and test the user messages.
- Hunting weak hashing in the codebase: Find every weak hash call used for passwords in the lab codebase, move them to one shared safe function and verify with tests.
- A different error message reveals the user: Prove the login page returns a different message for a missing user and switch to one uniform message.
- A login with no lockout: Add progressive delays and a per-account limit to a login that allows unlimited attempts and test that the lock does not turn into a denial of service.
- A predictable remember-me token: Prove the remember-me token is built from the username and replace it with a random, server-side hashed, expiring token.
- A skipped step in account recovery: Prove the security question step can be skipped in the password reset flow and close it by tracking flow state on the server.
- The TOTP secret leaks in a response: Find the TOTP secret returned more often than needed in the MFA setup response and fix it so it is shown only during setup.
- The second step can be skipped: Prove protected pages are reachable after the password step without visiting the MFA page and restrict the session until MFA completes.
- Unlimited TOTP attempts and the time window: Show there is no attempt limit and the window is too wide in TOTP verification, fix both and make backup codes single-use.
- Login with WebAuthn: verify registration properly: Find missing origin and challenge checks in the lab's WebAuthn registration and complete the server-side verification.
- A failed-login pattern: password spraying: Find the source making a few attempts against many accounts in the authentication log and report the time window.
- A stuffing attack and a successful login: Pick out the accounts that logged in successfully from a credential stuffing wave and list the actions for those accounts.
- Alerts and hardening for login attacks: Harden the login flow, write two alert rules for spraying and stuffing and test both with replayed attack traffic.
About this course
You apply in code and in Burp how passwords should be stored, the disclosure and brute-force risks in the login flow and the correct set-up of MFA and passkeys.
What you will learn
- Passwords
- The login flow
- Multi-factor authentication
Prerequisites
Finishing the level 101 courses of the same path, or knowing those topics, is enough.
Lab environment
Lessons run on your own Kali Linux desktop in the browser, with the tools ready in their windowed interfaces. Nothing to install; a computer screen is recommended.
Frequently asked questions
- Is this course right for my level?
- The course is at level 201; it assumes you know the topics of the lower-level courses.
- Is there anything to install?
- No. Every lesson runs in your own lab environment that opens in the browser.
- How do lessons work?
- Each lesson has 8 to 10 steps and a short quiz. Early steps show the command to type, later steps give less help; if two attempts fail, the solution opens.
- Can I try it for free?
- Yes. The first three lessons of every course are free.