What Is Salting in Security? Password Hashing and Salting Explained

What is salting in security?

Salting means adding a unique, random value (the salt) to each password before it is hashed. As a result, identical passwords produce different hashes. The salt does not need to be secret and is stored together with the hash (OWASP, NIST SP 800-63B-4).

Passwords are not lost at login – they are lost when a database falls into the wrong hands. Whether attackers then have instant access to accounts or face a much harder task depends on how the passwords were stored. Here you will learn how hashing and salting work, which algorithms are recommended today and how to migrate an existing system securely.

What is password hashing?

Password hashing uses a hash function to convert a password into a fixed-length string. This string – the hash value – looks completely different from the original password and cannot be reversed. Only the hash value is stored, never the password itself. Typical algorithms are Argon2, scrypt and bcrypt.

This matters for two reasons. If a database containing plaintext passwords is compromised, attackers can access all accounts immediately; hash values are unreadable. And because the function is one-way, even the operator of a platform cannot reconstruct a password. Leaked plaintext passwords also enable account takeover and credential stuffing, because many people reuse the same password on several services.

What is the difference between hashing and encryption?

Encryption is reversible; hashing is not. A message is encrypted with a key and can later be decrypted with the matching key. The goal is to keep information confidential, for example during transmission. Hashing cannot be reversed, which makes it ideal for verifying passwords: at login, the password entered is hashed again and compared with the stored hash – without the password itself ever having to be stored.

• Encryption = recoverable (e.g. for data transmission)
• Hashing = one-way function (e.g. for password verification)

How does salting work, step by step?

When a user sets a password, the system generates a new random salt, hashes the password together with the salt and stores the salt and the hash. At login, verification works like this:

1. The user enters the password.
2. The system reads the associated salt and hash from the database.
3. It hashes the password entered with the same salt and the same parameters.
4. The result is compared with the stored hash.
5. If the values match, the login is successful.

The password itself is never stored – only the hash values decide.

Why do you need a salt if you already hash passwords?

Because without a salt, identical passwords produce identical hashes. Attackers could then use precomputed tables (rainbow tables) to recognise passwords instantly; OWASP names this as exactly what a salt protects against. With a salt, they would have to recalculate every single hash. Example:

• Users A and B both use “Password123”
• Without salt: same hash → easy to attack
• With salt: completely different hashes → much harder to attack

What is the difference between salt and pepper?

A salt is unique per password and stored with the hash; a pepper is a secret shared across passwords and stored separately from the database. The table compares them:

How long should a salt be?

NIST SP 800-63B-4 requires a salt of at least 32 bits. OWASP names no length and notes that most libraries generate and manage salts automatically, so you rarely handle them by hand.

Which algorithms are recommended in 2026?

OWASP calls Argon2id the best choice for password hashing and names scrypt as the fallback if it is not available. bcrypt is for legacy systems, and PBKDF2 applies if FIPS-140 compliance is required. These are the OWASP minimum values:

The values are minimums: benchmark them on your own system. A password hashing function should be slow, and the work factor can be raised as hardware becomes more powerful; NIST asks for a cost factor as high as practical without hurting verifier performance. Memory-hard designs such as Argon2id also make attacks with graphics cards (GPUs) harder.

Why are MD5 and SHA-1 unsuitable for passwords?

Because they were designed to be fast, while password hashing functions should be slow. Fast hashes let attackers try large numbers of guesses quickly, including on GPUs. OWASP also states that fast hashing algorithms such as SHA-256 are not suitable for password storage. NIST describes SHA-1 as having reached the end of its useful life because of collision attacks and plans to stop using it by 31 December 2030 (NIST).

How do you migrate existing hashes?

Migrating existing systems is technically demanding but feasible:

1. Introduce a new method: e.g. Argon2id instead of SHA-1 or MD5.
2. Secure existing hashes immediately: The old hash values are hashed again with the new method (“hash wrapping”, or layering in OWASP’s terms). This protects the database immediately without waiting for logins.
3. Migrate at the next login: When someone logs in, the password is hashed directly with the new method and the old value is replaced.
4. Version your hashes: Store the algorithm and parameters with each hash, for example in the PHC string format that OWASP names. NIST SP 800-63B-4 likewise asks to store a reference to the scheme and the cost factor.
5. Optional: encourage a password change: Ask users to set a new password to speed up the migration – and ideally also offer two-factor authentication or alternatives to passwords.

Test the migration carefully and log it. For your technical and organisational measures, document the algorithm and its parameters, the date of the last review and the migration log. A security risk assessment helps you decide how strict the parameters need to be.

Is salting required under the GDPR?

No. Art. 32(1) GDPR does not prescribe a specific method such as hashing or salting. It requires technical and organisational measures that are appropriate to the risk, taking into account the state of the art, the costs and the nature, scope, context and purposes of processing (Art. 32 GDPR). Which method is appropriate depends on your risk assessment; OWASP and NIST SP 800-63B-4 are useful references for documenting your choice, but they are not legal requirements.

If passwords do leak, the breach must be reported to the supervisory authority without undue delay and, where feasible, within 72 hours, unless it is unlikely to result in a risk (Art. 33(1) GDPR). Our guide to reporting a data breach explains how. More on how such measures fit together: security controls in companies.

Conclusion

Password hashing and salting are not optional in practice: only then do login credentials remain protected even if a database falls into the wrong hands. Art. 32 GDPR does not prescribe a specific method, but it expects measures that are appropriate to the risk and the state of the art, and OWASP and NIST give concrete guidance for password storage. Use Argon2id for new systems, use a unique salt for every password and review the work factor regularly. MD5, SHA-1 and plaintext storage are unsuitable for password storage.

It gets even more secure when passwords are no longer the only hurdle. Our article on secure alternatives to passwords shows which methods are suitable.

Secure password hashing can be documented as one of your technical and organisational measures under the GDPR. With heyData, you document your security measures in a structured way and are better prepared for audits and customer requests.

Take the first step towards clean security documentation. Book a demo now!