What is the difference between salting and key stretching for password protection?

Why This Matters for Security Teams

Salting and key stretching are often discussed as if they solve the same problem, but they defend against different parts of the offline attack chain. Salting stops attackers from using precomputed tables and from spotting password reuse by identical hashes. Key stretching raises the computational cost of guessing each password, which matters when hashes are stolen and attackers can test them at scale.

The distinction is not academic. Weak password storage still shows up in incidents where secrets and credentials are exposed in code, config, or poorly controlled stores, and the blast radius can be immediate. NHI Management Group notes that 96% of organisations store secrets outside secrets managers in vulnerable locations, which is a reminder that password protection failures usually sit inside broader identity hygiene issues, not just one hash function choice. See the Ultimate Guide to NHIs — What are Non-Human Identities and the NIST Cybersecurity Framework 2.0 for the broader governance context.

In practice, many security teams encounter the real cost of weak password storage only after hashes have already been exfiltrated and offline cracking is underway.

How It Works in Practice

A salt is a unique, random value added to each password before hashing. Its job is to make identical passwords produce different hashes, so attackers cannot reuse precomputed rainbow tables or immediately detect password reuse across accounts. A salt does not need to be secret, but it must be unique enough to defeat mass precomputation.

Key stretching, by contrast, deliberately slows the hashing process. Instead of hashing once, the system applies the password through many iterations or a memory-hard function so each guess costs more time and hardware. Current guidance generally favors modern password hashing functions such as Argon2, bcrypt, scrypt, or PBKDF2, with the exact choice depending on platform constraints and policy requirements. The goal is to make large-scale guessing economically unattractive even if the attacker has the hash file.

• Use a unique salt per password or per credential record.
• Store the salt alongside the hash, since secrecy is not the goal.
• Prefer a slow, memory-hard algorithm where possible, not a fast general-purpose hash.
• Tune work factors so legitimate logins remain usable while cracking becomes costly.
• Reassess parameters over time as hardware gets faster.

This lines up with the broader identity lessons documented in NHI Management Group research, including the fact that Schneider Electric credentials breach illustrates how exposed credential material can become an operational issue, not just a cryptographic one. For implementation guidance, pair this with the NIST Cybersecurity Framework 2.0 and modern password storage guidance from security engineering teams.

These controls tend to break down when legacy systems hard-code fast hashes or when authentication performance limits are treated as a reason to skip work factors entirely.

Common Variations and Edge Cases

Tighter password hashing often increases CPU and memory overhead, requiring organisations to balance login latency against resistance to offline cracking. That tradeoff becomes more visible in high-scale authentication systems, mobile back ends, and older applications that were never designed for memory-hard functions.

There is no universal standard for this yet across every platform, but best practice is evolving toward unique salts plus strong key stretching everywhere a password is stored. A salt alone is not enough, because it does not slow guessing. Key stretching alone is also incomplete, because without a unique salt, attackers can still compare and precompute at scale. Some systems add a pepper, which is a separate secret held outside the database, but that is a different control and should not be confused with salting.

Teams also need to distinguish password storage from broader secret management. If passwords, API keys, or tokens are stored in code or configuration, the hashing discussion is already too late in the chain. The operational lesson is simple: choose a modern password hash, use a unique salt every time, tune the work factor, and remove plaintext secrets from places they should never have been.

Related resources from NHI Mgmt Group

• What is the difference between role-based access and API key governance for NHI security?
• What is the difference between attack surface management and NHI governance?
• What is the difference between reviewing human access and reviewing NHIs?
• What is the difference between human IAM controls and NHI governance?