Unit 7: Logins, MFA and tokens · Lesson 1 of 7 · 16 min
How a login works
The server never compares your password itself, only a hash of it.
mission
- You are
- The analyst reviewing the shop's sign-in.
- Situation
- Before reviewing password storage, you want to know exactly what the sign-in form sends and how the server answers success and failure.
- Goal
- Compare the responses to a right and a wrong password.
- Hand in
- The differences between success and failure, header by header.
Checking a password
Press play or step through.
A wrong password
curl -si -d 'user=learner&password=wrong' http://127.0.0.1:8000/login | grep -iE '^(HTTP|set-cookie|cache)'
HTTP/1.1 401 Unauthorized
Cache-Control: no-store
you should see 401, no cookie, and no-store so the page is never cached.
curl- Sends web requests and prints the response. Built into Linux, macOS and Windows 10 and later.
grep- Prints the lines of text that match a pattern. Built into Linux and macOS.
A user that does not exist
curl -s -d 'user=nobody&password=wrong' http://127.0.0.1:8000/login | grep Wrong <p>Wrong user or password.</p> curl -s -d 'user=learner&password=wrong' http://127.0.0.1:8000/login | grep Wrong <p>Wrong user or password.</p>
you should see Identical messages. Nobody can use the form to find out which accounts exist.
The right password
curl -si -d @shop-account.txt http://127.0.0.1:8000/login | grep -iE '^(HTTP|location)'
HTTP/1.1 303 See Other
Location: /account
you should see 303 to the account page, plus the session cookies you met earlier.
Is the login page cached?
curl -sI http://127.0.0.1:8000/login | grep -i cache-control
Cache-Control: no-store
you should see no-store: a shared computer will not keep a copy of the form or its answers.
What a defender takes away
- 1Failures should look the same whether the user exists or not.
- 2Sign-in responses must never be cached.
- 3The server only ever compares hashes.
Questions
0 of 2 solved
Answer each one from what you find on your lab machine.