Node.js course · Part 6: Accounts · lab 6 of 9
Who you are, and what you may do
Passwords stored so a stolen database is worthless, sessions that expire and rotate, and permission checks that deny by default. The two halves of auth, kept apart.
By the end you can
- Explain why a password is never stored, only a salted hash of one
- Store and verify a password without ever keeping the password
- Issue, expire and destroy sessions, and rotate one on sign-in
- Write permission checks that deny by default and cannot be fooled by an id
Easier if you did first
step 1 of 4
Two different questions
Auth is two questions that get muddled constantly. Who are you, and what are you allowed to do? Authentication is the first. Authorisation is the second. Getting the first right tells you nothing about the second.
An airport does both and keeps them apart. The passport desk decides who you are. The gate decides whether this boarding pass gets you on this plane. Proving your identity brilliantly does not get you into the cockpit.
Most serious breaches are failures of the second one. Someone signs in perfectly legitimately, changes an id in a URL, and reads another customer's invoice. The system knew exactly who they were and never asked whether they were allowed.
The other half of this step is passwords. The only safe assumption is that your database will be read by someone one day. Everything you store is designed around that.
Five questions.
What these words mean
- authentication
- Proving who you are. Signing in.
- authorisation
- Deciding what you may do. Checked on every action.
- hash
- A one-way fingerprint. You cannot turn it back into the password.
- salt
- Random text added per password, so identical passwords hash differently.
- session
- A record on your server that a cookie points at.
- IDOR
- Changing an id in a request to reach somebody else's data.
question 1 of 5
Why store a hash rather than the password?
question 2 of 5
Why is SHA-256 the wrong choice for passwords?
question 3 of 5
What does a per-user salt stop?
question 4 of 5
A signed-in customer changes /api/invoices/41 to /api/invoices/42 and sees someone else's invoice. What failed?
question 5 of 5
Why issue a new session id when someone signs in?