Never Store Passwords in Java

Until now, sign-up wrote the password itself into the users table. If that table ever leaks, every account is open, and many people use the same password on other sites too. A shop should never store passwords.

Hashes: store a hash instead, a one-way scramble of the password: easy to compute, no way back. The course gives you a helper, hashPassword, built on Java's PBKDF2 (javax.crypto). It also mixes in a random salt from randomHex(8), so the same password gives a different result every time:

System.out.println(hashPassword("tulip7"));   // pbkdf2:sha256:600000$...$...
System.out.println(hashPassword("tulip7"));   // another salt, another hash

The result holds the method, the salt and the hash, split by $. With your changes, the test requests get:

POST /register  {"email": "ana@example.com", "password": "secret123"}  →  201  {"email": "ana@example.com", "id": 1}
POST /register  {"email": "ana@example.com", "password": "hello456"}   →  409  {"error": "Email already registered"}
POST /register  {"email": "ben@example.com", "password": "secret123"}  →  201  {"email": "ben@example.com", "id": 2}
POST /register  {"email": "ben@example.com", "password": "other789"}   →  409  {"error": "Email already registered"}

Ana and Ben chose the same password, yet their rows share nothing but the method: each sign-up got its own salt.

Your task: in the constructor's CREATE TABLE, name the last column password_hash instead of password. In register, compute String passwordHash with hashPassword, then insert the email and the hash with RETURNING id to get the new int id. The helpers are already there.

Assignment
Follow the Coding Tutorial to store a salted hash at sign-up instead of the password.

Hint
Hash only after the 409 check. data.get("password") is an Object, so cast it with (String) before passing it to hashPassword; then pass passwordHash as the second value of the INSERT.