• Use a vetted library to hash sensitive data

It's a pretty big security risk to store human readable passwords in databases. Even in very secure systems, there's always a chance that somebody could break in and steal your data - we need to be prepared for that. So how do we hide things like passwords if we still need to store them so users can actually log in to our app?

We hash them!

Hashing is a one-way system that transforms any piece of data into gibberish. There is no way to transform the data back into its original state, making it a highly effective solution for storing and verifying sensitive information such as passwords.

Hashing is:

• Deterministic: The same input will always produce the same output.
• One-way: It's practically impossible to reverse a hash back to its original data form.

Since hashing is both deterministic and one-way, it's a great solution for storing passwords in a database. Even if somebody gains access to the data, they won't be able to un-hash the password to see what it was - but we can still verify a user has entered their password correctly because we can hash what they enter and compare the hash to the one stored in the database.

Let's imagine a user creates an account and enters the password "mypassword". We don't want anybody, even the developers, to know what their password is so we hash it and store the hash in the database instead. The SHA256 hash of mypassword is and always will be 89e01536ac207279409d4de1e5253e01f4a1769e696db0d6062ca9b8f56767c8, that's what we store.

Later, the user tries to log in using that password, "mypassword". We use the same hashing algorithm to hash what they enter and then compare the resulting hash to the one stored in the database when they created their account.

The password they entered was the same, we used the same hashing algorithm to hash them, so the resulting hash is exactly the same! That's how we hide passwords from prying eyes while maintaining our ability to verify login credentials.

Even if somebody broke into our database and saw the hash, there's no way they'd be able to reverse it back into mypassword since it's a one-way system.

1. Fork this repository and clone the fork.
2. Rename .env.example to .env
3. Create a new database instance in ElephantSQL, then edit the DATABASE_URL variable in .env, swapping YOUR_DATABASE_URL for the URL of the database you just created. Leave ?schema=prisma at the end.
4. Edit the SHADOW_DATABASE_URL variable in .env, swapping YOUR_SHADOW_DATABASE_URL for the URL of the shadow database you created in the earlier exercises. Leave ?schema=shadow at the end.
5. Add your JWT secret string
6. Run npm ci to install dependencies.
7. Run npx prisma migrate dev to execute the database migrations. Or npx prisma migrate reset to reset database and run all migrations - press y when it asks if you're sure.

In this exercise, you'll be using the bcrypt package to hash a user's password upon account registration and then compare it during login.

You can choose to implement the full solution yourself or complete a partially built solution. It's recommended to attempt building the solution yourself first.