What Is Password Hashing and Salting?

Why is storing passwords securely so important?

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 nearly impossible task depends on how the passwords were stored. Password hashing and salting are the standard for this. Here you will learn how both methods 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.

Why is password hashing necessary?

1. Protection in data breaches

If a database containing plaintext passwords is compromised, attackers can access all accounts immediately. Hash values, by contrast, are unreadable – and thanks to salting, they differ even for identical passwords.

2. One-way function

Hash functions cannot be reversed. Even the operator of a platform cannot reconstruct the original password. This also protects users against misuse by insiders or compromised administrator accounts.

3. State of the art and legal obligation

Under Art. 32 GDPR, companies must protect personal data with appropriate technical and organisational measures (TOMs) in line with the state of the art. Login credentials are part of this. Plaintext passwords or outdated methods such as MD5 do not meet the state of the art. ISO 27001 also requires secure handling of authentication information in Annex A (control 5.17).

Hashing vs. encryption: the difference explained

Hashing and encryption are often confused, but they serve different purposes. Encryption is reversible: 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, on the other hand, cannot be reversed. This 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.

In short:

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

Properties of secure hash functions

A hash function for passwords has to meet different requirements than a hash function for checksums:

• Slowness (computational cost): makes brute-force attacks harder
• Salt support: prevents rainbow table attacks
• Memory hardness: makes attacks with graphics cards (GPUs) and specialised hardware harder
• Adjustable parameters: the cost can be increased as computing power grows
• Maintained, reviewed algorithm: actively developed and analysed by experts

What is a salt – and why is it needed?

A salt is a randomly generated string that is created individually for each password and included in the hash. As a result, even identical passwords produce different hash values. Without a salt, attackers could use precomputed tables (rainbow tables) to recognise passwords instantly. With a salt, they would have to recalculate every single hash. The salt does not need to be secret and is usually stored together with the hash.

Example:

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

Additional protection with a pepper: A pepper is a secret value that is stored separately from the database, for example in a hardware security module or secrets manager. If only the database falls into the wrong hands, attackers lack this value to crack the passwords.

Recommended algorithms for password hashing

The Open Worldwide Application Security Project (OWASP) currently recommends the following methods and minimum values:

The German Federal Office for Information Security (BSI) has also recommended Argon2id for password-based key derivation in its technical guideline TR-02102-1 since 2020 – exactly the method on which secure password hashing is based. The values shown are minimums: how high you set them depends on your server performance and the acceptable waiting time at login.

Why MD5 and SHA-1 are insecure

MD5 and SHA-1 were not designed for passwords but for fast integrity checks. That is exactly their problem: they are so fast that attackers can try billions of passwords per second with a single graphics card. In addition, both are considered cryptographically broken: there are practical methods to create collisions, i.e. two different inputs with the same hash. This makes them completely unsuitable for passwords. Incidentally, the same applies to SHA-256 without salt and work factor: the algorithm is not broken, but it is also far too fast.

How password verification with hashes works

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 computational cost matters

Computational cost (work factor) is a key security feature: the more computing time and memory a hash requires, the fewer passwords attackers can try per second. Modern algorithms such as Argon2id or bcrypt can be configured so that hashing takes a few hundred milliseconds. Users barely notice this at login – but for attackers who want to test billions of combinations, it is a massive obstacle.

Important: Review the work factor regularly and increase it as available computing power grows.

Risks of insecure password storage

The biggest risks are:

• Account takeover and identity theft: If plaintext passwords are leaked, accounts can be taken over immediately.
• Credential stuffing: Many people use the same password for several services. Attackers test leaked credentials automatically on other platforms.
• Loss of trust and reputation: A data breach involving plaintext passwords can damage a company's reputation in the long term.
• GDPR violations and fines: Insufficiently protected passwords violate Art. 32 GDPR. If a breach occurs, you usually have to report it to the supervisory authority within 72 hours – our guide to reporting a data breach explains how.

How to migrate to modern hashing

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”). 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 method and parameters with each hash. The standard formats of Argon2id (starting with “argon2id”) and bcrypt (starting with “2b”) already include this information.
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.

It is important to test the migration carefully, log it and document it as part of your TOMs.

Conclusion

Password hashing and salting are not optional but mandatory: only then do login credentials remain protected even if a database falls into the wrong hands. Use Argon2id for new systems, use a unique salt for every password and review the work factor regularly. MD5, SHA-1 and plaintext storage have no place in modern systems.

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 is part of your technical and organisational measures under the GDPR and a building block of every ISO 27001 certification. With heyData, you document your security measures in a structured way and are prepared for audits and customer requests.

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