How Does Password Hashing Protect Accounts?

Registration creates a verifier, not a sealed password

When a user creates an account, the service receives the password over an authenticated, encrypted channel. At the server, password-storage code generates a random salt for that account. It feeds the password, salt and cost parameters into a password-hashing scheme such as Argon2id, scrypt, bcrypt or PBKDF2, chosen according to current platform and policy guidance.

The function produces a fixed-length output often called a password hash, derived key or verifier. The service stores that output together with the salt and enough information to repeat the calculation: algorithm identifier, version and cost parameters. It should discard the plaintext password as soon as the authentication operation permits.

At login, the user supplies a candidate password. The server retrieves the account’s stored salt and parameters, applies the same function and compares the new output with the stored verifier. If they match, the password attempt is accepted, subject to other controls.

The comparison itself should avoid leaking how many initial bytes matched through timing differences. Mature libraries provide suitable verification functions. This is one reason application teams should use reviewed password-hashing libraries rather than inventing a format or comparison routine.

Hashing is not encryption

Encryption is designed to be reversible with a key. A service encrypts plaintext into ciphertext and later decrypts it when an authorized operation needs the original. Password hashing for login is designed as one-way verification: the service repeats the transformation on a guess rather than recovering the password.

“One-way” does not mean guesses are impossible. If an attacker guesses orchid-window-7, they can combine it with the stored salt, run the same public function and see whether the result matches. The function protects by making recovery require guesses, and by making every guess consume meaningful resources.

A website that emails a user their existing password has evidence that some recoverable form exists somewhere, although the precise implementation may vary. A standard password-reset flow does not need to recover the old password. It verifies control through another authenticated process, lets the user choose a new secret and invalidates or replaces the old verifier.

Hashing also differs from a general fast cryptographic hash such as SHA-256. Fast hashes are excellent for file integrity and many cryptographic constructions. Their speed is a liability for password storage because an attacker can try enormous numbers of candidates. A password-hashing function is intentionally tunable and, in modern designs, often memory-hard.

The salt is public and still essential

A salt is a random value chosen for one stored password. It is normally saved beside the verifier. Its job is not to be a second secret.

Without unique salts, two accounts using the same password and function produce the same stored result. An attacker can recognize password reuse within the database and compute a candidate once for every identical verifier. Precomputed tables can also map common password hashes to likely plaintext.

With independent salts, the same password produces different verifiers. A candidate must be processed with Alice’s salt to test Alice and Bob’s salt to test Bob. Precomputation loses much of its reuse. RFC 9106 recommends a 16-byte salt for Argon2 password hashing and says the salt should be unique for each password. NIST SP 800-63B-4 requires salts of at least 32 bits and chosen to minimize collisions; real systems should follow their selected scheme and policy, commonly using substantially more than that minimum.

Salt does not strengthen the human password itself. If Alice chose a common word, an attacker will still try it early with Alice’s salt. Salt changes the economics across accounts; it does not make a predictable secret surprising.

The work factor makes every guess carry weight

Password-hashing schemes expose parameters that control computation. PBKDF2 repeats a pseudorandom function many times. bcrypt has a logarithmic cost. scrypt and Argon2 allocate memory as well as computation. The defender chooses settings that make one legitimate login tolerable while making millions of offline guesses expensive.

Argon2id is memory-hard: each calculation is designed to require a configured amount of memory and passes through it. An attacker can still parallelize, optimize hardware and trade memory against extra computation, but memory consumption raises the cost of running many guesses at once. RFC 9106 provides parameter recommendations for different memory constraints; applications must benchmark on their own servers and monitor denial-of-service risk.

Consider an illustrative server setting where one password verification takes 100 milliseconds on one core. Serially, that core can perform about:

1 second ÷ 0.1 second = 10 guesses per second.

A list of 10 million candidates would take about 1 million seconds, or 11.6 days, on that single serial worker. That is not an estimate of a real attacker’s time. Attackers use optimized code, parallel processors, GPUs or specialized hardware; functions behave differently on each platform; breached settings may be weak; and guesses are ordered, so a common password might fall immediately. The calculation shows only the multiplication principle: raising cost per guess raises total work.

The server also pays that cost for real logins. Settings that exhaust memory or CPU can become a denial-of-service problem. “As slow as possible” is not a policy. NIST says the cost factor should be as high as practical without harming verifier performance and increased over time as computing improves.

A breach changes the game from online to offline

During an online login attack, the service can rate-limit attempts, detect unusual behaviour, delay responses, challenge the user or lock an account under carefully designed rules. The attacker must ask the service about each guess.

If the password-verifier database is stolen, the attacker can test guesses offline. There is no server rate limit. The attacker has the salts, hash settings and verifiers because those values are required for normal verification and are not assumed secret. Protection now rests on the function’s cost, any separately protected server secret and the passwords’ resistance to guessing.

This is why database hashing is breach containment, not breach prevention. Access control, secure coding, patching, database segmentation, monitoring and incident response are still required. If attackers steal active sessions, reset tokens or application secrets, password hashing may not address the path they used.

An offline breach also reveals why password reuse is dangerous. Once attackers recover a password from one weaker site, they can try the same email-password pair at other services through credential stuffing. The stronger site’s excellent hashing cannot make a reused password unknown again.

A pepper changes where the attacker must reach

NIST SP 800-63B-4 says verifiers should perform an additional keyed hashing or encryption operation using a secret key known only to the verifier, stored separately from the hashed passwords and preferably protected by hardware. Security practitioners often call such a server-side secret a pepper.

If an attacker steals only the password table but not the pepper, offline verification becomes much harder. But the operational burden grows. The secret must be generated, stored, accessed, rotated and recovered securely. Unlike a per-user salt, it cannot simply sit in the same database without losing the separation benefit.

A pepper is not a substitute for salt. One shared secret does not prevent same-password patterns unless the base password hashing also uses unique salts. It is also not magic after a full server compromise: an attacker who can invoke the running verifier or steal the protected key may bypass its benefit.

The history began with multi-user machines

Robert Morris and Ken Thompson’s 1979 paper “Password Security: A Case History” described the UNIX password system and the pressure created by predictable human choices. The system used a modified one-way encryption calculation and a 12-bit salt, making precomputed attacks less reusable across accounts and deliberately slowing guesses by the standards of the time.

The numbers are obsolete; the design lessons remain recognizable. Verification data should not expose plaintext. Different accounts should not share one reusable transformation. Guessing should cost something. Users will choose patterns. Defences must evolve as computers become faster.

Modern password hashing inherited those goals and added decades of cryptographic analysis, standard formats and memory-hard designs. It also inherited the arms race: parameters that were adequate years ago may be cheap now. Stored algorithm and cost metadata allow a service to upgrade a verifier after the user successfully logs in, rehashing the password under current settings without knowing it beforehand.

A good password makes the hash’s work count

Offline guessing is not an even walk through every possible character string. Attackers start with breached passwords, common phrases, keyboard patterns, names, dates and transformations such as adding a year or exclamation mark. A 20-character quotation may be more predictable than a random 12-character manager-generated value.

NIST’s current guidance emphasizes password length, blocklists of commonly used or compromised values, password managers and avoiding arbitrary composition rules that push users toward predictable substitutions. It requires at least 15 characters when a password is the sole authentication factor and permits a minimum of eight when it is used as part of multi-factor authentication, within the federal digital identity framework.

Those are verifier requirements, not a promise that every 15-character phrase is strong. For users, the practical choice is a password manager generating a unique password for each service. A memorable passphrase may be appropriate for the manager’s master password when created from genuinely independent words and protected with multi-factor authentication.

Never paste a real password into an online “hash tester” or strength meter. A safe observation uses a made-up phrase that protects no account. Change one character and run both test strings through an offline educational hashing tool or reviewed library. The outputs should change completely. Repeat with the same password and two different salts: the verifiers should differ. This demonstrates sensitivity and salting, not real-world security.

Hashing does not solve phishing

The password must still be presented during login. A convincing fake site can capture it before the legitimate service hashes it. Malware can record keystrokes. An attacker can trick customer support, steal a reset channel or hijack a signed-in session. NIST explicitly notes that passwords are not phishing-resistant.

Multi-factor authentication adds an independent factor, but methods differ. One-time codes can also be phished in real time. Cryptographic authenticators such as passkeys can bind authentication to the legitimate site and provide stronger phishing resistance. Recovery workflows must be protected too; otherwise the attacker walks around the front door.

The lesson is not that passwords are useless. It is that a stored verifier addresses one threat: exposure of the password database. Secure authentication is a system of enrollment, transport security, hashing, rate limiting, breach detection, session management, recovery and additional authenticators.

The database record is a recipe card with no ingredient

A mature stored record often encodes the algorithm, version, cost, salt and verifier in a standard string. That record tells the server exactly how to test a candidate. It also lets the server recognize an outdated cost.

After a successful login under old settings, the service already has the correct plaintext in memory for that moment. It can generate a new salt, apply the stronger configuration and replace the record. Accounts that never return may require a forced reset if the legacy scheme becomes unacceptable. Migration therefore needs policy, logging and careful compatibility handling.

When verifiers leak, time becomes a defensive resource

A service that discovers password-verifier exposure should not wait to learn which hashes were cracked. It needs to contain the access path, preserve evidence, invalidate risky sessions and reset affected credentials according to the incident. Users need a clear notice describing which system was exposed, whether salts and parameters were included, what action to take and why reused passwords elsewhere are at risk.

Hash quality changes the response window but does not remove the response. Strong, expensive verifiers and unpredictable user passwords may delay recovery. Weak legacy hashes or common passwords may fall quickly. Because defenders cannot know every attacker’s hardware or candidate list, they should not publish a confident countdown to safety.

Monitoring after reset matters too. Attackers may have already authenticated, created recovery methods, issued API tokens or changed account details. Resetting one password without terminating sessions can leave the compromised path open. Authentication logs, token inventory and customer-support procedures are part of password storage’s real perimeter.

This incident view explains why hashing settings belong in asset records. A company should know which applications use which schemes and costs before a breach, not discover an obsolete format during one.

The server has not created a secret it can reverse. It has stored a recipe for testing an ingredient that the user must supply again.

This is the honest power of password hashing: the inevitable stolen database contains friction instead of answers. Whether that friction lasts minutes or centuries depends largely on the password, the scheme, the settings and what else the attacker obtained.

Continue exploring

Three questions to read next.

Technology & EngineeringHow Does a Computer Chip Use Ones and Zeros?Read next →Technology & EngineeringHow Does an LED Produce Light?Read next →Technology & EngineeringHow Do Undersea Internet Cables Carry the World’s Data?Read next →

Browse all Flash Science explainers →