How do we store passwords safely in the database? How do we validate a password a user enter against what we store in the database. Let's take a look. It is essential to store passwords in a way that keeps an attacker from getting them even if the database is compromised. Let's talk about what not to do first. Do not store passwords in plain text. Anyone with internal access to the database can see them. If the database is compromised an attacker could easily get all the passwords. So what should we do to safely store passwords in the database. The Open Web Application Security Project (also known as OWASP) provided some guidelines on how to store passwords. Here are the recommendations. First, use a modern hashing algorithm. Hashing is a one-way function. It is impossible to decrypt a hash to obtain the original value. If an attacker obtains the hashed password, they cannot just enter it into the application to gain access. It is important to use a modern hashing function designed to securely store passwords. These are sometimes characterized as "slow" functions that use more resources to compute. This makes brute force attacks unattractive. Note that some common legacy hashing function like MD5 and SHA-1 are "fast". They are less secure and should not be used. Second, salt the passwords. According to the OWASP guidelines, a salt is a unique randomly generated string that is added to each password as a part of the hashing process. Why do we need to salt the password at all? Well, storing a password as a one-way hash is a step in the right direction, but it is not sufficient. An attacker can defeat one-way hashes with pre-computation attacks. Some common attacks are rainbow tables and database-based lookups. With these techniques, a hacker could crack a password in seconds. By adding a salt that is unique to each password to the hashing process, it ensures that the hash is unique to each password. This simple technique makes pre-computation attacks unattractive. Let's take a look at how we store a password with a salt. We first combine the password provided by the user with the randomly generated salt. We then compute the hash of this combination using an appropriate hashing function. The hash is stored in the database along with the salt. Again, the salt is used to generate a unique hash. It is not a secret and can be stored safely as plain text in the database. Finally, let's take a look at the process in reverse. When a user logs in, how do we validate the password against what is stored in the database? First, we fetch the salt for the user from the database. We then append the salt to the password provided by the user and hash it. We compare this computed hash against the hash stored in the database. If they are the same the password is valid. That's it about storing passwords in the database. If you would like to learn more about system design, check out our books and weekly newsletter. Please subscribe if you learned something new. Thank you so much, and we'll see you next time.