Files
What you'll learn
- Tell hashing from encryption, and say which one a password gets and which one data you must read back gets
- Hash a password with bcrypt at a chosen cost and check a sign-in with compare, never by comparing strings
- Derive an encryption key from a password with scrypt and encrypt with aes-256-ctr under a fresh IV per message, storing the IV with the ciphertext
- Read the shape of a bcrypt hash and of a stored ciphertext, and know what each gives away (nothing)
Press Run tests to start the app. Its log appears here.Graded endpoints
A new member of staff; the response names her and says nothing about her password. The store accepts the value only because it is a bcrypt hash
Usernames are unique
compare() ran her password through the same salt and cost and got the stored hash back
A different password hashes to something else entirely
The seeded account was hashed at boot the same way
The token verifies as before: hashing changed how a password is checked, not how a token works
Public, and empty until john adds a cat
Signed in, john adds a cat; the microchip column is empty until staff record one
Nothing to decrypt yet
The cat comes back as stored: the microchip column holds an IV and a ciphertext, not the number
The public read returns the ciphertext, which gives the number away to nobody
Decrypted with the IV stored in front of it and the key derived at boot
Any signed-in member of staff; the key belongs to the service, not to a user
The decrypted number is for staff only
The cat is looked up before anything is decrypted
The encrypted microchip goes with the record
Tom is gone