Password Hashing and Salting: Stop Plaintext Leaks
Salting prevents attackers from using precomputed rainbow tables to reverse your entire database in a single pass.
Password hashing converts secrets into fixed-length strings. Salting adds unique random data to each password before hashing. This combination ensures identical passwords produce different hashes, stopping bulk cracking attempts and protecting users if your database is stolen.
The Library Analogy for Password Hashing and Salting
Imagine you run a library where patrons hand you notes with their secrets. You never read these notes. Instead, you run them through a one-way shredder. The shredded output is the hash. If two patrons write "secret123", the shredder produces the same pile of paper. An attacker stealing your filing cabinet sees two identical piles. They realise the secrets are identical. They only need to crack one to compromise both accounts. This is the vulnerability of unsalted hashing.
Salting changes this dynamic. You mix each note with a unique handful of sand before shredding. Now, even if two patrons use the same secret, the shredded output differs completely. The attacker sees two distinct piles. They must crack each one individually. This simple addition of random data transforms a bulk attack into a labour-intensive, per-account struggle.
What Is Password Hashing and Salting
Password hashing is the process of transforming a password into a fixed-length string using a mathematical function. This function is one-way, meaning you cannot reverse the hash to retrieve the original password. Salting involves appending or prepending a unique, random string of data to the password before the hashing process occurs. Together, password hashing and salting create a defence that relies on uniqueness and computational difficulty.
The mechanism works by ensuring that the input to the hash function is always unique, even for identical passwords. The salt is stored alongside the hash in your database. When a user logs in, the system retrieves the salt, combines it with the entered password, hashes the result, and compares it to the stored hash. If they match, access is granted.
| Aspect | Detail |
|---|---|
| Purpose | Prevent plaintext exposure and bulk cracking |
| Salt Length | Minimum 16 bytes per user |
| Algorithm | Argon2, bcrypt, or scrypt |
| Storage | Salt stored in same record as hash |
| Cost Factor | Configurable iterations to slow processing |
| Weakness | Reused salts or fast MD5/SHA1 functions |
Who It Affects and Why It Matters
Every organisation that stores user credentials is affected by the quality of its password storage. This includes software vendors, web applications, and internal identity providers. The impact extends beyond your infrastructure. When you store passwords poorly, you endanger your users across all their accounts. People reuse passwords. A breach at your service gives attackers the keys to their email, banking, and social media.
You are liable for the negligence of storing credentials in reversible or weakly protected formats. Regulatory frameworks often classify plaintext passwords as a critical failure. Even if you encrypt the database, the encryption key is often accessible to the application running the queries. If an attacker gains database access, they likely have the ability to decrypt the data. Hashing removes the plaintext entirely. There is nothing to decrypt.
What People Usually Get Wrong
Many developers misunderstand the role of the salt. They treat it as a secret key. It is not. The salt must be stored publicly alongside the hash. Its purpose is uniqueness, not secrecy. Hiding the salt provides no security benefit because the attacker already has the hash. If you hide the salt, you are likely implementing a flawed custom scheme.
Another common error is using a global salt. This is a single value added to every password in the system. This fails to prevent rainbow table attacks. The attacker simply incorporates the global salt into their precomputation. The result is identical to having no salt at all. Each password requires its own independent, cryptographically random salt.
A third mistake is choosing fast hashing algorithms. Functions like MD5 or SHA-256 are designed for speed. This speed benefits the attacker, not the defender. You want the hashing process to be slow. This increases the time it takes to test a single guess. This time penalty multiplies across billions of guesses, making brute-force attacks impractical.
How to Implement Secure Storage
Select a modern, adaptive hashing algorithm. Argon2 is currently the preferred choice due to its memory-hardness. It requires significant RAM to compute, limiting the attacker's ability to use parallel hardware like GPUs. Bcrypt and scrypt are acceptable alternatives if Argon2 is unavailable. Avoid legacy algorithms entirely.
Generate a cryptographically secure random salt for each user. Use at least 16 bytes. This length ensures a negligible probability of collision. Store the salt in the same database row as the hash. Do not store it in a separate table or configuration file. This simplifies the verification process and prevents desynchronisation.
Configure the cost factor appropriately. This parameter controls the computational work required for each hash. Set it as high as your application latency allows. The login process should take no more than a few hundred milliseconds. This slight delay is imperceptible to users but significantly hinders attackers. Test performance under load before deployment.
See also: What full disk encryption protects against and how it fails · What Does Personally Identifiable Information Mean and How to Protect It
The Hidden Cost of Legacy Systems
Upgrading password storage is rarely a simple configuration change. Legacy systems often rely on outdated algorithms embedded in core libraries. Refactoring these systems requires careful planning. You must support existing hashes while transitioning new users to the stronger algorithm.
This creates a dual-state system. Some users have weak hashes. Others have strong hashes. During login, the system must detect the hash type. If it is weak, it verifies the password and then re-hashes it with the new algorithm. This gradual migration ensures security improves without locking out users.
However, this approach carries risk. During the transition window, some accounts remain vulnerable. Attackers may target these weak hashes specifically. Monitor login attempts closely. Implement rate limiting to slow down brute-force attacks on weak accounts. Prioritise migrating high-privilege accounts first.
Related Security Controls
Password storage is one layer of defence. It does not replace other security measures. You must integrate it with broader identity and data protection strategies. For instance, full disk encryption protects data at rest on physical devices. This prevents theft if a server is physically stolen. It does not help if the database is compromised remotely.
Data retention policies also play a role. If you do not need to keep old passwords, delete them. Reducing the amount of stored data reduces the impact of a breach. Combine this with data inventory and mapping to ensure you know where every credential store resides. Unmapped databases are often the weakest link.
Consider the broader threat of data extortion. Attackers may threaten to release stolen credentials unless paid. Strong hashing mitigates this by rendering the stolen data useless. The attacker cannot prove they have usable passwords. This removes the leverage for extortion. See our guide on data extortion for strategies on handling such threats.
Checklist for Implementation
Review your current password storage method. Identify the algorithm and salt usage. Check for global salts or missing salts. Plan a migration path to a modern algorithm like Argon2. Generate unique salts for all new registrations. Re-hash existing passwords upon successful login. Monitor performance and adjust cost factors. Document the process for future audits.
- Audit current hashing algorithm
- Verify unique salt per user
- Select Argon2, bcrypt, or scrypt
- Configure appropriate cost factor
- Implement re-hashing on login
- Test performance under load
Key takeaways
- Unique salts per password defeat rainbow table attacks
- Slow hashing algorithms increase attacker computational costs
- Legacy systems often reuse salts, creating systemic risk
Unique salts and slow hashing algorithms render stolen password databases useless to attackers. Audit your current storage method and migrate to Argon2 or bcrypt immediately.
Frequently asked questions
Can I use a timestamp as a salt?
No. Timestamps are predictable and not unique enough. Attackers can guess them. Use a cryptographically secure random number generator instead.
Do I need to salt my API keys?
API keys are secrets, not passwords. They should be hashed if stored, but salting is less critical if they are unique. Treat them with similar care to passwords.
How long should a salt be?
A minimum of 16 bytes is recommended. This provides sufficient entropy to prevent collisions. Longer salts offer no significant additional security benefit.
How this guide was produced: written by the Honeypot Daily editorial team with AI assistance, checked against the public references listed below, and reviewed when the facts change. See our editorial policy or report an error.
