Category: Passwords & Hashing

Password Hashing

Also known as: Password Hash, Salted Password Hashing

Simply put

Password hashing is a one-way process that converts a plaintext password into a fixed-length string of characters called a hash, using a cryptographic hashing algorithm. Because the operation cannot be reversed, systems can store the hash instead of the actual password, so the original password is not exposed if the stored data is compromised. When a user logs in, the system hashes the entered password and compares it to the stored hash rather than comparing the plaintext directly.

Formal definition

Password hashing applies a cryptographic hash function to a plaintext password to produce a fixed-size, one-way digest that is quick to compute but computationally hard to reverse. Hashing differs fundamentally from encryption: it is one-directional and there is no key that recovers the original input, which is why hashing rather than reversible encryption is the standard approach for password storage. In most deployments, a per-password salt is combined with the input before hashing to defeat precomputed lookup and rainbow-table attacks, and purpose-built password hashing algorithms (for example bcrypt) are typically preferred over fast general-purpose hashes because their deliberate computational cost slows brute-force attempts. Verification is performed by hashing a submitted password under the same parameters and comparing the resulting digest to the stored value. Note that the specific algorithm choice, salting, and work-factor configuration vary by deployment; this entry does not cover authentication protocol flows or credential transport, which are separate concerns.

Why it matters

Password hashing is the baseline defense for credential storage. Because a hash is a one-way digest that cannot be reversed to recover the original input, a system that stores hashes rather than plaintext passwords does not directly expose usable credentials if its stored data is compromised. This matters because credential databases are a frequent target, and the difference between storing plaintext and storing properly hashed passwords often determines whether a data exposure becomes an immediate account-takeover event or a slower, harder problem for an attacker.

The protection hashing provides is not absolute and depends heavily on configuration. General-purpose cryptographic hashes are designed to be fast to compute, which also makes them faster for an attacker to guess against at scale. For this reason, purpose-built password hashing algorithms such as bcrypt are typically preferred because their deliberate computational cost slows brute-force attempts. Similarly, a per-password salt is used in most deployments to defeat precomputed lookup and rainbow-table attacks; without it, identical passwords produce identical hashes and become vulnerable to precomputed attacks.

For security architects and engineers, the practical takeaway is that adopting hashing is necessary but not sufficient. The specific algorithm choice, salting practice, and work-factor configuration collectively determine how much real protection the stored hashes offer, and these parameters need to be revisited as computational capabilities change.

Who it's relevant to

IAM Engineers and Developers

Engineers implementing or maintaining credential stores need to choose a purpose-built password hashing algorithm such as bcrypt over a fast general-purpose hash, ensure a per-password salt is applied, and set an appropriate work factor. They are also responsible for the verification path, where a submitted password is hashed under the same parameters and compared to the stored digest rather than compared in plaintext.

Security Architects

Architects designing credential storage decide the standards for algorithm selection, salting, and work-factor configuration across systems. They must account for the fact that hashing protection depends on these parameters and that fast general-purpose hashes offer weaker resistance to large-scale brute-force guessing than deliberately costly password hashing algorithms.

Compliance and Audit Leads

Those responsible for assessing credential-handling practices need to confirm that passwords are stored as one-way hashes rather than as plaintext or reversible encryption, and that salting is in place to resist precomputed and rainbow-table attacks. Because implementations vary, verifying the specific algorithm and configuration is part of a meaningful review.

Inside Password Hashing

One-way hash function

A cryptographic function that transforms a password into a fixed-length digest that cannot be feasibly reversed to recover the original input. Password hashing relies on this irreversibility so that the stored value does not disclose the plaintext credential.

Salt

A unique, random value combined with each password before hashing. Salts ensure that identical passwords produce different digests and defeat precomputed lookup attacks such as rainbow tables. Salts are typically stored alongside the hash and are not required to be secret.

Work factor (cost parameter)

A tunable parameter that controls how computationally expensive the hashing operation is, typically expressed as iteration count, memory cost, or parallelism depending on the algorithm. Higher work factors slow down brute-force attacks at the expense of authentication latency.

Purpose-built password hashing algorithms

Algorithms designed specifically to be slow and resource-intensive for password storage, in contrast to fast general-purpose hashes. Commonly cited examples include bcrypt, scrypt, PBKDF2, and Argon2. The appropriate choice depends on deployment constraints and available library support.

Pepper (optional secret)

An additional secret value applied during hashing that, unlike a salt, is kept separate from the stored hash, often in application configuration or a secrets manager. Its use is optional and depends on the deployment's threat model.

Verification process

The step performed at authentication time in which a submitted password is hashed using the stored salt and parameters, then compared against the stored digest. This supports credential verification (authentication) and is distinct from what a principal is subsequently authorized to do.

Common questions

Answers to the questions practitioners most commonly ask about Password Hashing.

Is password hashing the same as encrypting passwords?

No. Encryption is a reversible operation that requires a key to decrypt the ciphertext back to the original value, whereas password hashing is a one-way transformation intended to be computationally infeasible to reverse. Systems should not store passwords in a recoverable encrypted form when a hash is what the verification flow requires; verification is done by hashing the presented password and comparing it to the stored hash, not by decrypting anything. Conflating the two often leads to inappropriate designs where password material could be recovered by anyone with access to the key.

Does adding a salt make a fast hash function like a plain SHA-256 safe for storing passwords?

Not on its own. A unique salt per password defeats precomputed lookup tables such as rainbow tables and ensures identical passwords produce different stored values, but it does nothing to slow down an attacker guessing candidates against a single stolen hash. General-purpose fast hashes are designed to be fast, which benefits an attacker performing large numbers of guesses. Password storage typically calls for a purpose-built password hashing function with a tunable work factor, in addition to salting, rather than a fast cryptographic hash alone.

How do you verify a login if the hash cannot be reversed?

Verification does not require reversing the hash. In a typical flow the system retrieves the stored hash (and its associated salt and parameters) for the identified account, applies the same hashing function with the same salt and parameters to the password presented at authentication time, and compares the result to the stored value. A match indicates the presented password is correct. This keeps the stored value one-way while still supporting authentication. Note this describes the authentication step only; it does not address what the authenticated principal is authorized to do.

How should the work factor or cost parameter be chosen and maintained over time?

The work factor is generally tuned so that a single hash computation takes an acceptable amount of time on your authentication infrastructure while remaining tolerable for legitimate login volume. Because hardware improves, a value chosen today may become too weak later, so many deployments periodically reassess and increase it. A common pattern is to rehash a user's password with updated parameters at their next successful login, since the plaintext is available only at that moment. Appropriate values depend heavily on the chosen algorithm, hardware, and traffic, so treat any specific number as configuration-dependent rather than universal.

Where should the salt be stored, and does it need to be secret?

A salt does not need to be secret; its purpose is uniqueness, not confidentiality. It is typically stored alongside the resulting hash, and many password hashing function output formats encode the salt, algorithm identifier, and parameters together in a single string so verification can reconstruct the exact computation. Each password should have its own randomly generated salt. Some designs additionally use a separate secret value kept outside the database, but that is a distinct construct from the salt and should not be confused with it.

What should happen to stored password hashes when you change hashing algorithms or parameters?

Because the original passwords are not recoverable from the stored hashes, you generally cannot re-hash existing credentials in bulk under a new algorithm without the plaintext. A common approach is to record which algorithm and parameters produced each stored value, continue verifying existing hashes with their original settings, and transparently upgrade each record to the new scheme the next time that user successfully authenticates. This allows a gradual migration; records for accounts that never log in again may need a separate policy decision, which is deployment-specific.

Common misconceptions

Hashing and encryption are the same thing, so a hashed password can be decrypted if needed.

Password hashing is intended to be a one-way transformation with no decryption key, whereas encryption is reversible with the correct key. A stored password hash is not designed to be reversed to plaintext; verification works by re-hashing the submitted input and comparing digests.

A fast, secure cryptographic hash such as a general-purpose SHA family function is a good choice for storing passwords.

Speed is a liability for password storage because it lets attackers try many candidates quickly. Purpose-built, deliberately slow algorithms with a tunable work factor (such as bcrypt, scrypt, PBKDF2, or Argon2) are typically preferred over fast general-purpose hashes.

Salts must be kept secret to be effective.

Salts are primarily intended to ensure uniqueness per credential and to defeat precomputed attacks; they are typically stored alongside the hash and do not need to be secret. A secret value kept separately is instead referred to as a pepper.

Best practices

Use a purpose-built, deliberately slow password hashing algorithm (such as bcrypt, scrypt, PBKDF2, or Argon2) rather than a fast general-purpose hash, selecting the specific algorithm based on your library support and deployment constraints.

Generate a unique, random salt for every password and store it alongside the resulting hash so that identical passwords do not produce identical digests.

Tune the work factor (iteration count, memory, and parallelism as applicable to the chosen algorithm) so that hashing is expensive for attackers while keeping authentication latency acceptable, and revisit these parameters periodically as hardware improves.

Consider adding a pepper stored separately from the hash (for example in a secrets manager) where the threat model warrants an additional secret, treating it as optional and distinct from the salt.

Re-hash stored credentials with updated algorithms or parameters when users next authenticate successfully, allowing gradual migration to stronger settings without knowing the plaintext.

Keep password hashing scoped to credential storage and verification (authentication), and handle what an authenticated principal may do through separate authorization mechanisms.