In an increasingly connected world, simply storing or encrypting passwords is no longer enough. Cybercriminals are constantly developing new methods to steal sensitive data — which is why stronger protection mechanisms are needed. Password hashing and salting are among the most effective methods for protecting your credentials from misuse. In this article, we'll explain how these technologies work — and why they should be standard practice in every secure IT infrastructure today.
What Is Password Hashing?
Password hashing is a process in which a password is converted into a fixed-length string using a so-called hash function. This string — known as the hash value — looks completely different from the original password and (in theory) can't be reversed. Typical algorithms for this include bcrypt, scrypt, or Argon2.
Why Is Password Hashing Necessary?
1. Protection in the Event of Data Leaks
If a database is compromised and passwords are stored in plain text, any attacker can access accounts immediately. Hashes, on the other hand, are unreadable — and thanks to additional security mechanisms like salting, they're even individually unique, even for identical passwords.
2. One-Way Function
Hash functions aren't reversible — meaning even the platform operator can't reconstruct the original password. This is an important principle of the "zero knowledge" concept in IT security.
1. Standard Practice in IT Security
Hashing (combined with a salt and a secure algorithm) is a recognized best-practice standard and is indirectly required by, among others, the GDPR and security standards such as ISO 27001.
Hashing vs. Encryption: The Difference Explained
Hashing and encryption are often confused, but they serve different purposes. Encryption is a reversible process — meaning a password or message is encrypted with a key and can later be decrypted again with the matching key. The goal is to keep information confidential over a certain period of time.
Hashing, on the other hand, isn't reversible. A hashed value can't be meaningfully converted back into the original password. This is why hashing is ideal for verifying passwords: at login, the entered password is hashed again and compared to the stored hash — without ever needing to store the password itself.
In short:
- Encryption = recoverable (e.g., for data transmission)
- Hashing = one-way function (e.g., for password verification)
Properties of Secure Hash Functions
A secure hash function for passwords must meet specific requirements:
- Slowness (computational intensity): Makes brute-force attacks harder
- Salt support: Prevents rainbow table attacks
- Resistance to parallel processing: Prevents efficient GPU or ASIC attacks
- Future-proofing: The algorithm should be actively maintained and security-vetted
- Memory hardening (in Argon2): Makes attacks with dedicated hardware harder
What Is a Salt — and What Is It Used For?
A salt is a randomly generated string that's added to the password before hashing. This ensures that even identical passwords produce different hashes. Without a salt, an attacker could use precomputed hash dictionary tables (known as rainbow tables) to instantly identify passwords. The salt renders this method practically useless, since the attacker would have to recompute for every hash and every salt.
Example:
- Users A & B both use "Password123"
- Without a salt: same hash → easily attackable
- With a salt: completely different hashes → more secure
Recommended Algorithms for Password Hashing
For secure password hashing, the following algorithms are considered today's best practices:
- bcrypt: Widely used, well-tested, supports salting, and has configurable computation time
- scrypt: Also memory-intensive → makes attacks with specialized hardware harder
- Argon2: Winner of the Password Hashing Competition (PHC), currently considered the most modern standard (especially Argon2id)
These algorithms offer protection against modern attacks and can be configured to match security requirements.
Why MD5 & SHA-1 Are Insecure
MD5 and SHA-1 were originally designed not for password security but for fast integrity checks. That's exactly their problem: they're far too fast, making them ideal for brute-force or dictionary attacks. Additionally, both algorithms are now cryptographically broken — meaning there are real-world methods for deliberately creating collisions, i.e., two different inputs with an identical hash. That doesn't just make them insecure; it makes them completely unsuitable for passwords.
How Password Verification with Hashes Works
At login, verification works as follows:
- The user enters their password.
- The system retrieves the corresponding salt and hash from the database.
- It hashes the entered password with the same salt.
- The result is compared to the stored hash.
- If the values match, authentication is successful.
The actual password is never stored or compared directly — only the hash values determine the outcome.
Why Computational Intensity Is Critical
Computational intensity (also called the work factor) is a security feature: the more computing time a hash requires, the harder it is for attackers to try millions of hashes per second. Modern algorithms like bcrypt or Argon2 can be configured so that a single hashing operation takes, for example, 200 milliseconds. For legitimate users, that's not a problem — but for attackers looking to test billions of passwords, it's a massive obstacle.
Important: The work factor should be reviewed regularly and adjusted if necessary as computing power increases.
Risks of Insecure Password Storage
The biggest risks are:
- Complete identity theft: If plain-text passwords are leaked, accounts can be taken over directly.
- Credential stuffing: The same passwords are often reused across multiple platforms — attackers test them automatically on other sites.
- Reputational and trust damage: A data leak involving plain-text passwords can ruin a company's reputation for the long term.
- GDPR violations and fines: Failure to protect personal data can lead to legal consequences.
How to Safely Migrate to Modern Hashing
The migration is technically demanding, but achievable:
- Implement a new hashing method (e.g., bcrypt instead of SHA1)
- Continue using existing passwords for now, but:
- Apply the new hashing algorithm at the next login or password reset
- Optionally, prompt all users to change their password to speed up migration
- If needed, introduce hash versioning (e.g., a hash with the prefix $2y$ for bcrypt)
It's important to make the migration transparent and secure — including testing, logging, and notifying users if necessary.
NIS2 Compliance with ISO 27001: A Practical Guide | heyData
Learn how ISO 27001 supports your NIS2 implementation, which gaps remain, and how to build a resilient information security and compliance system.
Free & no obligation
FAQ
What's the difference between hashing and encryption?
What's the difference between hashing and encryption?
What is a "salt" and why is it essential for security?
What is a "salt" and why is it essential for security?
A salt is a randomly generated string that's added to the password before hashing. This ensures that even identical passwords of two users produce completely different hash values. Without a salt, attackers could use precomputed tables (so-called rainbow tables) to crack hashed passwords in no time.
Which hash algorithms are considered secure, and which should no longer be used?
Which hash algorithms are considered secure, and which should no longer be used?
How does a system verify the password at login if it isn't stored at all?
How does a system verify the password at login if it isn't stored at all?
At login, the user enters their password. The system retrieves the salt associated with the email address/username from the database, appends it to the entered password, and hashes this combination with the same algorithm. If the newly calculated hash matches the hash value stored in the database, the login is successful — without the plaintext password ever having to be stored or transmitted.
