For normal login authentication, hash passwords; do not encrypt them. Store a unique, randomly generated salt and a verifier produced by a slow, adaptive password-hashing function such as Argon2id. Hashing is intentionally one-way, so a database theft does not hand an attacker a decryption key that reveals every password. Use reversible encryption only when a legacy integration genuinely requires the original secret and cannot be redesigned to use a token or delegated credential.
Hashing and encryption solve different problems
A password verifier only needs to answer “does this submitted password match?” It does not need to recover the original text. A password hash transforms the password into a value that is computationally impractical to reverse. During login, the application runs the submitted password through the same password-hashing function and compares the result with the stored verifier.
Encryption is reversible: ciphertext can be turned back into plaintext with a key. That is appropriate for data an application must later read, but it creates a high-value key and a direct recovery path if the key or decryption service is compromised. OWASP therefore treats encryption of passwords as an edge case and says to redesign the dependency when possible. See the OWASP Password Storage Cheat Sheet and Cryptographic Storage Cheat Sheet.
NIST SP 800-63B-4 states that “Verifiers SHALL store passwords in a form that is resistant to offline attacks” and that passwords “SHALL be salted and hashed using a suitable password hashing scheme.” The cost should be as high as practical without harming verifier performance (NIST SP 800-63B-4).
#1 Best Overall
- POWERFUL SECURITY KEY: The YubiKey 5 NFC is the most versatile physical passkey, protecting your digital life from phishing attacks. It ensures only you can access your accounts
- WORKS WITH 1000+ ACCOUNTS: Compatible with popular accounts like Google, Microsoft, and Apple. A single YubiKey 5 NFC secures 100+ of your favorite accounts, including email, password managers, and more
- FAST & CONVENIENT LOGIN: Plug in your YubiKey 5 NFC via USB and tap it, or tap it against your phone (NFC), to authenticate. No batteries, no internet connection, and no extra fees required
- MOST SECURE PASSKEY: Supports FIDO2/WebAuthn, FIDO U2F, Yubico OTP, OATH-TOTP/HOTP, Smart card (PIV), and OpenPGP. That means it’s versatile, working almost anywhere you need it
- PRIMARY & SPARE KEYS: Just like having a spare house key, we recommend buying two YubiKeys - one for daily use and one as a spare. That way you’ll never get locked out of your accounts
Choose a password-hashing algorithm
Use a maintained library’s password API rather than assembling a scheme from general-purpose hashes. The encoded record should carry the algorithm identifier and parameters so the verifier can understand old records and upgrade them later.
Argon2id: the default for new systems
OWASP’s preferred choice for new applications is Argon2id. Its current minimum example is 19 MiB of memory, two iterations, and parallelism of one. Treat those values as a starting point, not a universal security level: benchmark the complete login path on production-class hardware and increase or decrease the cost to make guessing expensive while keeping the service available.
Rank #2
- Security Key : Protect your online accounts against unauthorized access by using FIDO2 and U2F authentication with T120. It's the world's most protective security key that works with windows, Mac OS, Linux as well as Chrome, Firefox, Edge and many other major browsers.
- Certified with the new FIDO2 standard, T120 provides the benefit of fast login and strong protection against phishing, account takeover as well as many other online attactks.
- Works with : Bank of America, Github, Google, Microsoft, DUO, Twitter, Facebook, Dropbox, Apple, ebay, BINANCE, mor and more.
- Fits USB-C port : Insert the T120 security key into the USB-C port of each service and log in conveniently with one touch
- For the driver download and user guide, please visit TrustKey Solutions Home support page.
scrypt: a memory-hard fallback
If Argon2id is not available in your platform, OWASP lists scrypt with a minimum CPU/memory cost of 217, block size 8 (1,024 bytes), and parallelism 1. Use a reputable implementation and tune its actual latency in your deployment.
bcrypt: mainly for legacy compatibility
bcrypt remains useful when an existing system already depends on it. OWASP gives a minimum work factor of 10. Most bcrypt implementations accept no more than 72 bytes of input, so define and test an explicit password-length policy rather than silently truncating longer passphrases.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Rank #3
- ✅ PROTECT ONLINE ACCOUNTS – A password manager, two-factor security key, and secure communication token in one, OnlyKey can keep your accounts safe even if your computer or a website is compromised. OnlyKey is open source, verified, and trustworthy.
- ✅ UNIVERSALLY SUPPORTED – Works with all websites including Twitter, Facebook, GitHub, and Google. Onlykey supports multiple methods of two-factor authentication including FIDO2 / U2F, Yubico OTP, TOTP, Challenge-response.
- ✅ PORTABLE PROTECTION – Extremely durable, waterproof, and tamper resistant design allows you to take your OnlyKey with you everywhere.
- ✅ PIN PROTECTED – The PIN used to unlock OnlyKey is entered directly on it. This means that if this device is stolen, data remains secure, after 10 failed attempts to unlock all data is securely erased.
- ✅ EASY LOG IN –No need to remember multiple passwords because by plugging OnlyKey to your computer, it automatically inputs your username and password. It works with Windows, Mac OS, Linux, or Chromebook, just press a button to login securely!
PBKDF2-HMAC-SHA-256: when FIPS validation matters
For deployments that require FIPS-140 validated implementations, OWASP recommends PBKDF2-HMAC-SHA-256 with 600,000 iterations or more, tuned against the same latency and capacity constraints.
| Situation | Protection | Why |
|---|---|---|
| Check a user login | Salted Argon2id, or an approved fallback | Authentication needs a comparison result, not plaintext recovery. |
| FIPS-validated implementation required | PBKDF2-HMAC-SHA-256 at an appropriately tuned cost | PBKDF2 is OWASP’s preferred option for this constraint. |
| Legacy downstream system requires the original bytes | Authenticated encryption with tightly controlled key management, only after alternatives are exhausted | Recoverability is the requirement, so the key becomes a high-value secret. |
| Read-only password-database breach | Salted adaptive hashes, with an optional verifier-held pepper | Per-account, expensive offline guessing is required and one secret remains outside the database. |
Use salts correctly
A salt is a unique random value generated for each password with a cryptographically secure random source. Store it with the encoded verifier; it is not a secret. A distinct salt stops precomputed rainbow-table reuse and prevents an attacker from testing one guessed password once and applying the result to every account.
Rank #4
- ✅ PROTECT ONLINE ACCOUNTS – A password manager, two-factor security key, and secure communication token in one, OnlyKey can keep your accounts safe even if your computer or a website is compromised. OnlyKey is open source, verified, and trustworthy.
- ✅ UNIVERSALLY SUPPORTED – Works with all websites including Twitter, Facebook, GitHub, and Google. Onlykey supports multiple methods of two-factor authentication including FIDO2 / U2F, Yubico OTP, TOTP, Challenge-response.
- ✅ PORTABLE PROTECTION – Extremely durable, waterproof, and tamper resistant design allows you to take your OnlyKey with you everywhere.
- ✅ PIN PROTECTION – Locking your device means that if this device is stolen, data remains secure, after 10 failed attempts to unlock all data is securely erased.
- ✅ EASY LOG IN – No need to remember multiple passwords because by plugging OnlyKey to your computer, it automatically inputs your username and password. It works with Windows, Mac OS, Linux, or Chromebook, just press a button to login securely!
Argon2id, bcrypt, and PBKDF2 libraries generally generate and encode salts for you. Use those well-reviewed APIs instead of concatenating a home-grown salt or hashing with SHA-256 or MD5 directly.
Understand peppers and key protection
A pepper is an additional secret shared across verifiers. Unlike a salt, it must not be stored beside the password hashes. Keep it in a secrets vault or hardware security module, restrict access, monitor use, and design a rotation and recovery procedure before relying on it.
Best Value
- Ultra-Compact FIDO2 Security Key - Plug-and-stay or carry on a keychain. This USB-A hardware security key offers portable, always-on protection for desktop and mobile use. (Item Size: 0.75 X 0.74 IN x 0.25 IN)
- USB-A Hardware Key for All Devices - Works with USB-A ports on PC, Mac, Android, and other laptop/notebook device. Enables secure, cross-platform login with FIDO2.0 passkey support.
- FIDO Certified Security Key - Meets FIDO and FIDO2 standards. Works with Google, Microsoft, GitHub, Dropbox, and more. Please check service compatibility before purchase.
- Passwordless Login with Passkey - Supports passkey login via WebAuthn and CTAP2. Enjoy password-free sign-ins where supported. Not all websites or services currently support passkeys.
- Advanced Multi-Factor Authentication - Offers 200 FIDO2 passkey slots and 50 OATH-TOTP slots. Strong, flexible 2FA/MFA support across various apps and authentication platforms.
NIST also recommends an additional keyed-hashing or encryption operation using a secret known only to the verifier. A pepper is defense in depth: it does not replace a unique salt or an adaptive password hash, and losing the pepper can make every verifier unusable until a recovery plan is executed.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Implement verification and gradual upgrades
- Select the framework’s password-hashing API. Configure Argon2id or the context-appropriate fallback; never build a password scheme from a fast general-purpose hash.
- Store a standard encoded record. Include the algorithm identifier, cost parameters, salt, and derived hash in one field or a clearly associated set of fields.
- Verify with the library’s constant-time function. Do not decrypt a stored value or compare values with ad-hoc string logic.
- Rehash after a successful login when needed. If the stored algorithm or parameters are below the current policy, verify the old record, compute a new verifier, and replace it. This permits gradual migration from bcrypt or obsolete work factors without forcing a mass password reset.
- Protect the live authentication endpoint. Rate-limit attempts and use authenticated transport such as HTTPS. Password hashing limits damage from an offline database copy; it does not stop credential stuffing against a running service.
When reversible encryption is justified
Encryption is acceptable only when the application must recover the original secret—for example, an unavoidable legacy downstream system that accepts a password but offers no token, delegated-authentication, or one-time credential alternative. Treat this as an architectural exception, not a second password-storage option.
Controls for the exception
- Document why the dependency cannot be replaced with a token, delegated credential, or service-to-service identity.
- Use authenticated encryption so tampering is detected, not merely confidentiality-only encryption.
- Keep the encryption key in a managed key system or HSM, separate from the database and application backups.
- Restrict and audit decryption operations; avoid exposing plaintext in logs, traces, error messages, or support tooling.
- Plan key rotation, re-encryption, revocation, and recovery before storing the first credential.
If the original bytes are not genuinely required, do not create this recoverability path. A compromised encryption key can expose every stored password at once, whereas salted adaptive verifiers force an attacker into costly guessing for each account.
Quick Recap
Operational checks before launch
- Benchmark registration and login at expected concurrency on production-class hardware, including database and application overhead.
- Confirm that memory and CPU costs cannot be used to exhaust service capacity; add rate limits and sensible per-account and per-IP controls.
- Verify that salts are generated by the library and are different for different passwords, even when the plaintexts match.
- Test long passphrases against the selected algorithm, especially bcrypt’s common 72-byte input limit.
- Confirm that algorithm identifiers and parameters survive backups, migrations, and account recovery workflows.
- Define a policy for upgrading cost parameters and for retiring obsolete algorithms.
- Keep pepper and encryption keys outside the password database, with access logging and a tested recovery path.
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.
Recommended Free Tools
