Quick wins for a faster PC:
Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Clear out junk files and repair common Windows errorsFree Scan →Password hashing turns a password into a verifier that a system can check without storing the original password. A secure implementation uses a deliberately slow, memory-conscious password-hashing function, a unique random salt, and recorded cost parameters. At login, the submitted password is processed with those same settings and compared with the stored result; it is not decrypted.
Hashing limits the damage from a stolen password database, but it does not make weak passwords unguessable. An attacker can test guesses offline, so algorithm choice, password strength, rate limits, multifactor authentication and breach response all matter.
As an Amazon Associate I earn from qualifying purchases.
Password hashing in plain English
During signup, the server generates a unique salt, runs the password and salt through a password-specific hashing function, and stores an encoded verifier. That record normally includes the algorithm identifier, version, cost parameters, salt and derived hash. The plaintext password should not be retained. NIST requires at least a 32-bit salt and recommends keeping the scheme and cost factor with each verifier (NIST SP 800-63B-4).
- The user chooses a password.
- The application creates a cryptographically random, unique salt.
- A password-hashing function runs with the password, salt and tuned cost settings.
- The application stores the encoded result and its parameters.
At login, a maintained library reads those parameters, hashes the submitted password and performs the comparison:
#1 Best Overall
stored = database.get(user)
if password_verify(submitted_password, stored):
authenticate_user()
else:
reject_login()Use the verification API supplied by the library or framework rather than writing cryptographic comparison code yourself. It should handle parameter extraction and appropriate timing protections.
Hashing, encryption, encoding, salting and peppering
| Technique | Reversible? | Role in password systems |
|---|---|---|
| Hashing | No direct decryption | Verifies a password with a password-specific scheme |
| Encryption | Yes, with a key | Usually unsuitable for ordinary login verification |
| Encoding | Yes, by decoding | Never a security measure |
| Salting | Not a standalone transformation | Adds a unique random value to each password hash |
| Peppering | Not a standalone transformation | Adds a secret held outside the password database |
Encryption is appropriate only when an architecture genuinely must recover the original secret, such as a legacy service that accepts only the user’s password. Modern federation or delegated authorization is usually safer than designing recoverable passwords.
What a salt does
A salt is public, unique per password and generated with a secure random source. It makes identical passwords produce different stored values, defeats efficient bulk lookup tables and forces an attacker to attack each stolen verifier separately. It does not add meaningful entropy to a password such as password123, and it normally belongs in the same database record as the hash.
What a pepper does
A pepper is an additional secret shared by a set of verifiers. Keep it in a secrets manager, HSM, TEE or comparable protected system, never in the password database. It can help when an attacker steals only the database, but it is defense in depth, not a replacement for a suitable hashing function. Rotation is difficult: without the plaintext password, existing records generally cannot be recomputed under a new pepper.
Why SHA-256 alone is the wrong tool
MD5, SHA-1, SHA-256 and similar general-purpose hashes are designed to be fast. That lets an attacker test enormous numbers of guesses with GPUs or rented computing capacity. A password-hashing function deliberately consumes time and, in modern designs, substantial memory for every guess. SHA-256 inside PBKDF2-HMAC-SHA-256 is a different, approved construction from simply storing SHA256(password). OWASP explains the distinction in its Password Storage Cheat Sheet.
Work factors and memory-hardness
The work factor controls the resources required for each verification. Raising it increases an attacker’s cost and also the cost of every legitimate signup, login and reset. Choose the highest practical setting that preserves availability, benchmark it on production-like hardware and revisit it as infrastructure improves. Excessive settings can enable denial-of-service through many concurrent login attempts, so pair hashing with throttling, abuse detection and capacity controls.
A memory-hard function requires significant RAM as well as CPU time, making massive parallel cracking less economical on specialized hardware. Argon2id and scrypt are memory-hard schemes. Parameters from RFC 9106 target different environments: its lower-memory Argon2id profile uses 64 MiB, t=3, p=4, while its high-memory profile uses 2 GiB, t=1, p=4. Those profiles are not universal settings for a high-concurrency web login service (RFC 9106).
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Which password-hashing algorithm should you choose?
| Situation | Preferred direction | Important qualification |
|---|---|---|
| New application | Argon2id | Benchmark memory, latency and concurrency |
| Argon2id unavailable | scrypt | Tune N, r and p |
| FIPS or validated-module requirement | PBKDF2-HMAC-SHA-256 | Verify the exact validated implementation and configuration |
| Existing bcrypt database | Keep temporarily, then rehash | Check the implementation’s input-length behavior |
Argon2id
Argon2id is OWASP’s preferred general default for many new systems. Its listed baseline is at least 19 MiB of memory, two iterations and parallelism of one, with equivalent memory/time trade-offs such as 46 MiB at t=1 or 12 MiB at t=3. Treat these as starting points, not guarantees; measure verification time and RAM under realistic concurrent load. Use the library’s encoded format so the salt and parameters travel with each hash.
scrypt
Use scrypt when Argon2id is unavailable or mature scrypt support fits the platform. OWASP lists, among other options, N=2^17, r=8, p=1 (128 MiB), down to N=2^13, r=8, p=10 (8 MiB). These represent memory and parallelism trade-offs that still require local benchmarking.
PBKDF2
PBKDF2 is useful for FIPS-related or interoperability requirements. OWASP lists 600,000 iterations for PBKDF2-HMAC-SHA-256 and 220,000 for PBKDF2-HMAC-SHA-512; PBKDF2-HMAC-SHA-1 at 1,400,000 iterations is legacy guidance. These numbers must be tested and periodically reviewed, not treated as permanent universal values.
Rank #3
bcrypt
Bcrypt remains valuable for compatibility but is not the preferred new-system default. OWASP recommends a work factor of at least 10, subject to benchmarking. Many implementations accept only 72 bytes, not 72 visible characters; multibyte Unicode can reach that boundary sooner. Confirm your exact library and never silently truncate a password.
Avoid casually wrapping bcrypt around SHA-256 or SHA-512. Naive pre-hashing can create null-byte, truncation and password-shucking problems. A legacy integration that truly requires pre-hashing needs a documented, carefully designed construction, preferably with a secret pepper and printable encoding, followed by migration to a modern direct scheme.
yescrypt and other ecosystem choices
OWASP’s 2025 Top 10 names yescrypt alongside Argon2, scrypt and PBKDF2-HMAC-SHA-512 as strong adaptive choices (OWASP A04:2025). Its suitability depends on platform support, library quality and compliance requirements; that does not make it a universal replacement for Argon2id.
What a verifier record should contain
- Algorithm and version identifier.
- Cost parameters.
- Unique salt.
- Derived password hash.
Most modern libraries serialize these fields into one encoded string. Do not store plaintext passwords, a reversible encrypted copy without an exceptional architectural reason, one global salt, or a pepper beside the hashes. Do not discard algorithm metadata: it is what lets the application verify old accounts and upgrade them later.
What a breach changes
A stolen database enables offline cracking: attackers work directly against hashes and do not encounter the login endpoint’s rate limits. Weak or reused passwords may therefore be recovered and tried on other services. Online guessing, by contrast, passes through your application and can be throttled.
Recommended Free Tools
- Use a slow, salted password scheme and a breached-password blocklist.
- Require multifactor authentication for suitable accounts.
- Rate-limit and monitor login, reset and verification endpoints.
- Invalidate sessions and force resets when risk assessment or evidence of exposure warrants it.
Long passphrases should be supported. Define Unicode input handling consistently without destructive normalization, and document any algorithm-specific limits. Recovery codes and reset tokens are separate secrets: reset tokens should be high-entropy, single-use and time-limited; short lookup secrets need appropriate salted hashing.
Migrating legacy password hashes
An old password hash generally cannot be mathematically converted into a new one without the user’s plaintext password. The safest normal migration is login-time rehashing:
- Retain the legacy verifier temporarily.
- When the user logs in successfully, verify the supplied password with the old scheme.
- Immediately compute an Argon2id, scrypt or approved PBKDF2 verifier using the current parameters.
- Replace the old record and mark the account migrated.
- Set a deadline to expire remaining legacy records.
- Force resets for accounts that never return or whose old hashes are especially weak.
Use an immediate reset instead when hashes are plaintext, unsalted, based on MD5 or SHA-1, impossible to verify safely, or believed to have been accessed by an attacker.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Common implementation mistakes
- Storing plaintext or encoding passwords with Base64.
- Using reversible encryption for ordinary login verification.
- Using bare SHA-256, SHA-1 or MD5.
- Reusing one salt for every account.
- Hard-coding a pepper or placing it in the database.
- Choosing a cost so high that login abuse exhausts CPU or memory.
- Silently truncating long or Unicode passwords for bcrypt.
- Assuming that “hashing twice” is automatically safer.
- Omitting algorithm and parameter metadata.
- Writing bespoke cryptographic code instead of using a maintained library.
Should you build password authentication yourself?
A password hash is only one part of authentication. Secure systems also need reset and recovery flows, MFA, session management, account-enumeration defenses, abuse controls, Unicode handling, migration, secret management, audit and incident response. Use a framework-native helper or a maintained Argon2id, scrypt, bcrypt or PBKDF2 library with an encoded hash format.
If your team does not want to operate those surrounding systems, a managed identity service can reduce implementation risk. Auth0 targets customer identity, MFA, passwordless login, social and enterprise connections; its pricing page showed a free plan up to 25,000 monthly active users, with paid tiers and enterprise pricing beyond that on August 18, 2026. Amazon Cognito suits AWS-based applications and listed a 10,000-monthly-active-user free tier for qualifying Lite or Essentials direct/social users, with separate federation and messaging charges, on the same date. Vendor dependency, configuration complexity and recurring usage costs remain your responsibility.
Best Value
If the actual need is for employees to store administrator or infrastructure credentials, use a password manager rather than a customer-login provider. Bitwarden Business and 1Password Business address organizational credential management; neither is a password-hashing API for your application.
Frequently Asked Questions
Can password hashing be reversed?
A hash is not decrypted to recover the original password, but an attacker with the hash can test guesses offline. Strong, unique passwords and an appropriate slow hashing scheme make that process harder.
Is SHA-256 safe for storing passwords?
Not by itself. Use a password-specific function such as Argon2id, scrypt, bcrypt for legacy compatibility, or PBKDF2 when its compliance profile is required.
Do these 3 things before closing this tab:
1Fix the driver behind crashes, sound loss and screen glitches2Repair Windows errors before they cause bigger problems3Scan for outdated or missing drivers - takes under a minuteShould salts be secret?
No. Salts should be unique, random and stored with the verifier. A separate secret pepper is optional defense in depth.
Is bcrypt still secure?
It remains useful for existing systems when correctly configured, but Argon2id is generally the preferred default for new applications. Check bcrypt’s implementation-specific 72-byte input behavior.
How often should hashes be upgraded?
Rehash after a successful login when the stored algorithm or cost is below your current policy, then expire remaining legacy records on a defined schedule.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
