Skip to main content
Identity Authority
Category: Passwords & Hashing

Key Stretching

Also known as: Password Stretching
Simply put

Key stretching is a technique that makes weak or low-entropy secrets, such as passwords, harder to crack by deliberately making the process of testing each guess slow and computationally expensive. Rather than hashing a password once, the algorithm repeats the work many times so that an attacker attempting to guess the password must expend significantly more effort per attempt. This helps protect passwords even when the underlying secret has relatively little inherent randomness.

Formal definition

Key stretching is a cryptographic technique that strengthens weak or low-entropy secrets by repeatedly applying a computationally expensive hashing operation, intentionally increasing the work factor required to test each candidate guess. By iterating a secure hashing function (typically in conjunction with a per-secret salt to defeat precomputation), the technique raises the per-guess cost imposed on offline brute-force and dictionary attacks, thereby narrowing the advantage an attacker gains from cheap parallel hashing. The design goal is to make all bits of the derived key or hash dependent on the input secret while slowing the derivation enough to be tolerable for a single legitimate authentication but expensive at attacker scale. Note that key stretching addresses the cost of testing guesses and does not add entropy to an inherently weak password; the specific work factor, iteration count, and algorithm choice vary by deployment and configuration.

Why it matters

Passwords remain one of the weakest links in identity systems because users routinely choose low-entropy secrets that are vulnerable to dictionary and brute-force attacks. When a credential store is breached, attackers typically obtain hashed passwords and attempt to recover the plaintext offline, where they can test enormous numbers of guesses using cheap, highly parallel hardware. Key stretching directly targets this threat model by making each individual guess deliberately slow and computationally expensive, so that the attacker's advantage from mass parallel hashing is substantially narrowed.

The protection matters most precisely when a secret has little inherent randomness. A single fast hash of a weak password can be tested billions of times cheaply; by iterating an expensive hashing operation, key stretching raises the per-guess cost to a level that is tolerable for one legitimate authentication but punishing at attacker scale. It is important to understand the boundary of this benefit: key stretching increases the cost of testing guesses but does not add entropy to an inherently weak password. It buys time and raises attacker cost rather than making a poor password strong.

Who it's relevant to

IAM Engineers and Security Architects
Those designing credential storage and authentication flows need to select an appropriate key-stretching algorithm and tune its work factor. The specific iteration count and algorithm choice vary by deployment and configuration, and must balance legitimate authentication latency against the cost imposed on offline attackers.
System Administrators
Administrators operating password-backed systems should ensure that stored credentials are protected with salted, stretched hashes rather than single-pass hashing, and should revisit work-factor settings over time as hardware capabilities available to attackers increase.
Compliance Officers and Auditors
Those assessing credential-protection controls can treat the presence of salted key stretching as evidence of defense against offline brute-force and dictionary attacks. They should also recognize its limits: it mitigates the cost of guessing but does not compensate for weak password policies or inadequate entropy in the underlying secrets.

Inside Key Stretching

Work factor (cost parameter)
A tunable parameter that controls the computational effort required to derive a hash, allowing the cost to be increased over time as hardware improves. In bcrypt this is typically expressed as a cost or rounds value, and in PBKDF2 as an iteration count.
Salt
A unique, per-credential random value combined with the input before hashing to ensure identical inputs produce different outputs, defeating precomputed lookup and rainbow-table attacks. Key stretching typically depends on salting to be effective, but salting and stretching are distinct techniques.
Iteration / deliberate slowdown
The core mechanism of key stretching: repeatedly applying a cryptographic function so that verifying a single guess is intentionally slow, raising the aggregate cost of large-scale guessing attacks against low-entropy inputs such as passwords.
CPU-hardness vs. memory-hardness
Different algorithms resist attackers in different ways. PBKDF2 and bcrypt are primarily CPU-intensive; bcrypt uses a small, fixed amount of memory and is not memory-hard. Memory-hard functions such as scrypt and Argon2 additionally require significant memory, which raises the cost of parallelized attacks on GPUs and ASICs.
Password-hashing algorithms
Common key-stretching or password-hashing constructions include PBKDF2, bcrypt, scrypt, and Argon2. Selection depends on threat model, deployment constraints, and available library support; there is no single universally best choice.

Common questions

Answers to the questions practitioners most commonly ask about Key Stretching.

Is key stretching the same thing as encrypting a password?
No. Key stretching is a deliberately slow, iterated hashing (or key-derivation) process designed to make each guess of a password computationally expensive for an attacker. It produces a derived value used for verification or key material, not a reversible ciphertext. Encryption is reversible with a key; key stretching is a one-way transformation. Conflating the two leads to the mistaken assumption that a stretched value can be decrypted back to the original password, which it typically cannot.
Is bcrypt a memory-hard key stretching function?
No. bcrypt is CPU-intensive and uses only a small, fixed amount of memory, so it does not meet the accepted definition of a memory-hard password-hashing algorithm. Its work factor increases computational cost but does not meaningfully raise memory requirements, which limits its resistance to attackers using GPUs, FPGAs, or ASICs that parallelize CPU-bound work cheaply. Functions designed to be memory-hard aim to make large-scale parallel cracking more expensive by demanding substantial memory per guess; bcrypt is not in that category.
How do I choose a work factor or cost parameter for a key stretching function?
The goal is typically to make each derivation slow enough to hinder offline guessing while remaining acceptable for legitimate authentication latency. In most deployments teams benchmark on their target hardware and tune the iteration count, cost, or memory and parallelism parameters so a single derivation takes a tolerable amount of time under expected load. Because this depends on hardware, concurrency, and user-experience budgets, the appropriate value varies and should be revisited as hardware improves. Specific recommended values change over time and by algorithm, so consult current guidance for the function you deploy.
Should I still use a salt if I am using key stretching?
Yes. A per-credential salt is generally still required. Salting ensures that identical passwords produce different derived values and defeats precomputed lookup tables, while stretching raises the cost of each individual guess. They address different problems and are typically used together. Depending on the algorithm and configuration, additional inputs such as a separately stored secret (sometimes called a pepper) may also be layered on, though that is out of scope for the core definition of stretching.
How should I handle upgrading the work factor as hardware gets faster?
Because a fixed work factor becomes weaker as hardware improves, many deployments store the algorithm and parameters alongside the derived value so the cost can be raised over time. A common approach is to re-derive and re-store the value using the stronger parameters the next time the user authenticates successfully, since the plaintext password is only available at that moment. This lets you migrate incrementally without forcing a password reset, though the exact mechanics depend on your storage format and library support.
Where should key stretching happen, on the client or the server?
In most deployments the authoritative stretching is performed server-side so the server controls parameters and never trusts client-computed results as the sole protection. Client-side stretching can be used in some designs to reduce exposure of the raw password in transit or to derive local encryption keys, but it does not replace server-side verification hardening. Treat any client-supplied value as untrusted input and apply server-side controls regardless. The correct placement depends on your threat model and architecture.

Common misconceptions

Key stretching is a form of encryption that keeps passwords recoverable.
Key stretching is applied within one-way password-hashing schemes; it deliberately slows down hash derivation and does not produce a reversible ciphertext. A stretched, salted hash is designed to be verified against, not decrypted.
bcrypt is a memory-hard function.
bcrypt is CPU-intensive with a negligible, fixed memory footprint and does not meet the accepted definition of a memory-hard password-hashing algorithm. Memory-hardness is a property of algorithms such as scrypt and Argon2, which require substantial memory to compute.
A high work factor set once is sufficient indefinitely.
Work factors must be revisited as attacker hardware improves. A cost value that was adequate at deployment time may become too weak later, so the parameter typically needs periodic reevaluation and increase.

Best practices

Use a purpose-built password-hashing algorithm such as Argon2, scrypt, bcrypt, or PBKDF2 rather than a raw general-purpose hash function for storing credentials.
Always combine key stretching with a unique, sufficiently random per-credential salt so identical passwords do not yield identical stored hashes.
Calibrate the work factor (iteration count or cost parameter) to the highest value tolerable for your latency and throughput budget, and document the rationale.
Periodically review and increase the work factor as hardware capabilities advance, and rehash credentials opportunistically (for example, on next successful login) when parameters change.
Where the threat model includes GPU or ASIC-based guessing, prefer a memory-hard algorithm such as Argon2 or scrypt over CPU-only options like bcrypt or PBKDF2.
Treat algorithm and parameter selection as configurable and version-tagged in stored hashes so credentials can be migrated as recommendations evolve.
Application Security Isn’t Optional Anymore.