The password was 123456
A small firm's staff site lets people sign in with any password. Half of them chose 123456.
One evening someone tries a short list of common passwords against every name in the staff list. Within minutes they are in as the finance manager. The site had no limit on guesses.
The one rule
Warning
This lab is a set of lessons that are insecure on purpose. Attack your own private copy and nothing else. It has no way out to the internet. Never try these things on a site that is not yours: in the UK that is a crime under the Computer Misuse Act 1990.
By the end of this lesson
Note
I can say what makes a sign-in or a session weak.
Key words
| Word | What it means | Example |
|---|---|---|
| Session | the time during which a site remembers you are signed in | |
| Cookie | a small value the browser keeps and sends back to the site | |
| Token | a value that proves you signed in | a long string |
| Hashing | turning a password into a fixed string that cannot be turned back | |
| Brute force | trying many guesses one after another | |
| Expiry | the time after which a session or token stops working |
The cells students fill in are left blank in this preview.
Weak passwords fall to guessing
People choose short, common passwords. An attacker does not need cleverness, only a list of the common ones and a site that allows endless tries. That is brute force.
Three defences work together. Ask for length, not odd symbols. Refuse passwords on a common list. Slow or lock repeated failures.
Worked example: judging four passwords
| Password | Verdict | Why |
|---|---|---|
| 123456 | Refuse | On every common list |
| Summer2024! | Weak | A word, a year and a symbol is a pattern guessers know |
| bakery-lorry-seven-hats | Good | Long, and not a pattern |
| ana | Refuse | Too short, and the same as the user name |
The cells students fill in are left blank in this preview.
A site stores a hash, not the password
A site must never keep passwords as typed. If its records leak, every account leaks.
It stores a hash of the password and adds a random salt first, so two people with the same password have different hashes. To check a sign-in, it hashes the attempt and compares.
A session cookie is a key
After you sign in, the site gives your browser a session cookie and recognises you by it on every request. Anyone who holds that value is you.
So it must be random, long, sent only over HTTPS, hidden from script with HttpOnly, and it must expire. A site also issues a fresh one at sign-in.
Look at the lab's sessions
Your lab runs WebGoat. Start it and wait a minute. These three Runs look at the front door without signing in. The second asks for a page that needs a sign-in. The third shows the cookie the lab sets for it.
Is the sign-in page up?
curl -s -o /dev/null -w "%{http_code} %{redirect_url}\n" http://web/WebGoat/loginShown here, not run. Create a free account to press Run and type it into your own lab’s terminal.
A page that needs a sign-in
curl -s -o /dev/null -w "%{http_code} %{redirect_url}\n" http://web/WebGoat/welcome.mvcShown here, not run. Create a free account to press Run and type it into your own lab’s terminal.
The cookie that reply sets
curl -s -I http://web/WebGoat/welcome.mvc | grep -i "^set-cookie"Shown here, not run. Create a free account to press Run and type it into your own lab’s terminal.
What the three answers tell you
The first prints 200 and no address. The second prints 302 and the sign-in address, so a page behind sign-in sends strangers to the door. The third prints a JSESSIONID cookie with Path=/WebGoat; HttpOnly.
The value is random and changes every time. HttpOnly is present. It has no Secure, because this lab uses plain HTTP.
A common mistake
Warning
Many people think a token that looks like random letters is hidden. Encoding is not encryption. A token that only encodes the user name can be read and edited by anyone. Use a random session id the server looks up, or a token with a signature the server checks. Check the expiry too.
A token must be signed and must expire
Some sites give a signed token with the user name, a role and an expiry inside. The server checks the signature before it believes anything in it.
A token with no signature, a token the server does not check, or one that never expires is a weak token. Refuse all three.
Worked example: three tokens
| Token says | Signed? | Verdict |
|---|---|---|
| user ana, role customer, expires tomorrow | Yes | Accept |
| user ana, role admin, expires tomorrow | No | Refuse: nobody vouches for admin |
| user ana, role customer, expired last week | Yes | Refuse: expired |
The cells students fill in are left blank in this preview.