Never Store Passwords

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. generate_password_hash from werkzeug.security also mixes in a random salt, so the same password gives a different result every time:

from werkzeug.security import generate_password_hash

print(generate_password_hash("tulip7"))   # scrypt:32768:8:1$...$...
print(generate_password_hash("tulip7"))   # another salt, another hash

The result holds the method, the salt and the hash, split by $. The tests read the table through GET /check/users, a route the course adds for checking, which shows each different salt and hash as a numbered label. 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}
GET /check/users  →  200  [{"email": "ana@example.com", "id": 1, "password_hash": "scrypt:32768:8:1$<salt 1>$<hash 1>"},
                           {"email": "ben@example.com", "id": 2, "password_hash": "scrypt:32768:8:1$<salt 2>$<hash 2>"}]

Ana and Ben chose the same password, yet their rows share nothing but the method.

Your task: name the last column of CREATE TABLE password_hash instead of password, compute the hash in register, and save the hash instead of the password. The import is 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, then pass the variable password_hash as the second value of the INSERT.