What is Salt in Databases?
Salt is random data that is appended to passwords before hashing in order to make password cracking more difficult. It protects against rainbow table attacks, where attackers use precomputed hash tables to quickly reverse hash digests and find their original value.
When a salt is added to a password before hashing, it creates a unique hash value even if two users have the same password. This prevents attackers from being able to determine passwords by looking them up in rainbow tables.
Typical salts are random strings of 32 characters or longer. The salt does not need to be secret or encrypted. However, each password should have its own unique salt.
Why Use Salt?
Salting passwords before hashing adds an additional layer of security and prevents against common attacks like rainbow table attacks. As explained by TechTarget, “Password salting is a technique to protect passwords stored in databases by adding a string of 32 or more characters and then hashing them. Salting prevents efficient rainbow table attacks on hashed passwords in a database” (https://www.techtarget.com/searchsecurity/definition/salt).
Essentially, salting passwords before hashing them makes pre-computed hash attacks using rainbow tables ineffective. This is because the salt is unique for each password, meaning an attacker would need to compute a separate rainbow table for every single salted password to crack them. As noted by Auth0, “Salts prevent an attacker from building a rainbow table to crack all your hashed passwords in one go” (https://auth0.com/blog/adding-salt-to-hashing-a-better-way-to-store-passwords/).
Additionally, salting increases the complexity of brute force attacks. To crack a salted password hash, an attacker would first need to determine the salt used, and then run a brute force attack on each salted hash individually. This significantly slows down brute forcing attempts.
How Does Salting Work?
Salting passwords is a technique used to make password hashes more secure against brute force attacks. Here’s how it works:
When a user creates a password, a random salt value is generated. This salt value is unique for each password. The salt is then appended to the original password before the password is hashed.
For example, if the password is “password123” and the salt generated is “7x9dz”, the full string that gets hashed would be “password1237x9dz”.
The resulting password hash along with the random salt value is then stored together in the database. The salt does not need to be kept secret, and is stored plainly with the hash. But the salt value ensures that if two users have the same password, the hashes will still be different due to the different salt values.
When a user attempts to login, the submitted password gets concatenated with the stored salt value again, and the hash is recomputed and compared with the stored hash. This prevents brute force cracking methods that rely on precomputed hash tables.
Should Salt be Stored in DB?
Yes, salt should be stored in the database along with the hashed password. The purpose of salting passwords is to make each password unique, even if two users have the same password. The salt provides additional randomness to each password hash.
In order to verify a user’s password during login, the salt needs to be retrieved from the database to re-hash the entered password and compare it to the stored hash. As noted on Stack Overflow, “storing the salt in the DB next to the hashed password has always worked fine” for this purpose (Source).
The salt does not need to be secret or encrypted – it simply provides additional randomness. Storing the salt alongside the hashed password in the database is standard practice. When salting and hashing passwords correctly, retrieving the salt provides no advantage to an attacker trying to crack the passwords.
Best Practices for Salting
To properly implement salting when hashing passwords, it’s important to follow security best practices. Some key recommendations include:
Generate a new random salt per password. Salts should be unique per password so that if one password hash is cracked, it does not aid in cracking others. Using a cryptographic pseudo-random number generator (PRNG) or the OS randomness source helps create salts with high entropy.
Use cryptographic hashing algorithms designed for passwords. Functions like PBKDF2, bcrypt, and scrypt handle salting and key stretching built-in, making proper implementation easier.
Store salts separately from hashed passwords. Salts do not need to be secret and can be stored plainly with the hashed output. But keeping salts separate provides an extra defense in case the password database is compromised.
Use long, random salts. Salts should be at least 16 bytes long to prevent rainbow table attacks. Generating long, random salts maximizes their effectiveness in preventing pre-computed hash attacks.
Recommended Salt Length
The recommended salt length is at least 16 bytes, often 32-64 bytes. Salts should be sufficiently long and random to prevent brute-force attacks. As noted on crypto.stackexchange.com, “50 bit n [salt length], 500 bit n [salt length]. No difference, because the salt is known and simply added to all the brute force password values being hashed.” Therefore, a longer salt does not necessarily provide more security if the salt value is known. The key is to generate a new, random salt value for each password.
According to LoginRadius, “Ideally, the length of Salt should be as long as the output of the hash.” Common hash output lengths are 128, 160, 256, 512 bits. So ideal salt lengths would be 16, 20, 32, or 64 bytes.
Storing Salt
When it comes to storing salt, the two main options are storing it in the same table column as the password hash or in a separate database column. According to security experts, the best practice is to store the salt in the same column as the password hash. As this Stack Exchange post explains, “The salt can and should be stored right next to the salted and hashed password. Additionally, the salt should be unique per password.”
Storing the salt and hash together helps ensure they stay paired together, preventing any mix-ups if a separate salt table was used. It also simplifies the database design. While you could store the salt in a separate column, it provides no security or storage benefits. The only advantage is that it keeps the salt visibly separate from the hash, but this is just an organizational preference.
In summary, the standard recommendation is to store the unique salt together with each password hash. This provides simplicity while still allowing salts to be randomly generated per user.
When to Re-Salt Passwords
There are two main scenarios when it is recommended to re-salt passwords:
1. When changing hashing algorithms – If you decide to upgrade to a more secure password hashing algorithm, it is a good idea to generate new random salts and re-hash all the passwords. This ensures each password gets the full benefit of the improved algorithm.1
2. After password database is compromised – If your password database gets leaked or hacked, you should notify users to reset their passwords. When users reset their passwords, new salts should also be generated. This protects against rainbow table attacks targeting the compromised salts.2
Common Hashing Algorithms
There are several common password hashing algorithms used today for securely storing passwords. Some of the most widely used include:
- Argon2 – This is a modern algorithm designed to be resistant against GPU cracking attacks. It is the winner of the Password Hashing Competition in 2015. Argon2 comes in two main variants – Argon2i is optimized against side-channel attacks, while Argon2d is optimized against GPU attacks.
- PBKDF2 – PBKDF2 applies a pseudorandom function like a cryptographic hash or HMAC to the password and salt repeatedly. This makes brute force attacks harder. PBKDF2 allows configuring the number of iterations to increase computational cost.
- Bcrypt – Bcrypt is an adaptive password hashing function that adjusts the cost of hashing based on the speed of the system. This prevents brute force attacks from gaining advantage with faster hardware. Bcrypt truncates passwords longer than 72 bytes.
- Scrypt – Scrypt is a password-based key derivation function designed to be memory-hard, making it resistant to hardware brute force attacks. Scrypt’s memory hardness allows it to scale with future advancements in CPU parallelization and computing power.
These algorithms help protect stored passwords by making password cracking computationally expensive. Proper salting and frequent re-hashing further increase security against pre-computed hash attacks.
Conclusion
Salt is crucial for the secure storage of passwords in databases. When a password is hashed and stored in a database without salt, hackers can easily crack it using rainbow table attacks. Salting passwords before hashing them significantly increases protection against these brute force cracking attempts.
For salting to work properly, the salt needs to be stored in the database alongside the salted hash. When a user attempts to log in, the salt is retrieved from the database and added to their password entry before hashing. The resulting hash is compared to the salted hash stored for that user to verify their identity and grant access.
Storing salts in the database is standard practice and does not compromise security. The salt has no value on its own and cannot be used to obtain the original password. Only the combination of salt plus password can generate the correct hash for matching. Proper password salting and storage is crucial for database security.