RC: W1 D4 — Salting
February 15, 2024Today, I went to a talk that p.b. gave about creating an authentication system from scratch and I learned a ton! In particular, she mentioned a concept called “salting” that I had never heard of. Salting is a mechanism that allows to enhance the security of stored passwords.
Passwords are usually hashed before being stored in the database so that, if the database is compromised, the original passwords cannot be retrieved directly. Also, because hash functions do not allow for the reverse operation, we cannot derive the password from the hashes.
However, attackers have developed a method to crack the passwords: the rainbow table attack. Its principle is the following: the attacker generates a “rainbow table” by applying a particular hash function to many possible plaintext passwords. The table thus maps the computed hash to the plaintext password. If the attacker has access to the hashed password stored in a database, they can it look up in the rainbow table. If it is found in the table, then, they have cracked the password, i.e. they have access to the plaintext password.
Salting allows to fight against this attack by adding a random string (the “salt”) to the password before it is hashed. Thus, the stored value is the hash value of the password + the salt. Therefore, if an attacker gets access to the stored value, finding it in the rainbow table will not help (unless the table has been generated for each unique salt — but that is virtually impossible because it would require an incredible amount of computational resources).
In practice, when we use salting (or more likely: when an encryption algorithm uses salting), a new salt is generated for every new password stored. The salt is stored in plaintext together with the hashed value of the password + salt. When we need to verify the validity of the user’s password, we append the salt to the password they entered, hash the value and compare it to the hash stored in the database. If they are equal, the user is authenticated.