Hash them, with a slow password hashing algorithm and a unique salt. Do not encrypt them. Encryption is reversible, so anyone who gets the database and the key gets every password. OWASP says passwords should not use reversible encryption, and that secure password hashing algorithms should be used instead.
Hashing and encryption are different tools
| Property | Hashing | Encryption |
|---|---|---|
| Reversible | No | Yes, with the key |
| Needs a key | No | Yes |
| Typical goal | Check a value without storing it | Keep data secret but recoverable |
| Fits passwords | Yes | No |
You never need to read a user's password back. You only need to check whether what they typed matches. A hash gives you that without keeping the original.
Why speed is the enemy
A general hash such as SHA-256 is designed to be fast. That helps in many places and hurts for passwords, because an attacker with stolen hashes can try guesses at enormous speed. Password hashing algorithms are deliberately slow and can be tuned. OWASP's current guidance lists:
| Algorithm | OWASP minimum setting |
|---|---|
| Argon2id (preferred) | 19 MiB memory, 2 iterations, 1 parallelism |
| scrypt | N of 2 to the 17, r of 8, p of 1 |
| bcrypt | Work factor 10 or more, 72 byte limit |
| PBKDF2 | HMAC-SHA-256, 600,000 iterations, for FIPS-140 needs |
Salt and pepper
A unique salt must be added to each password, and most libraries do this for you. OWASP describes a pepper as a shared secret stored separately from the database. It adds defense in depth but gives no security alone, and if it is compromised, users must reset passwords.
Steps for a new system
- Pick Argon2id through a maintained library.
- Use the library's default salt generation and its encoded output string, which holds algorithm, parameters and salt.
- Set parameters at or above the OWASP minimums, and test the login time on production hardware.
- Store the output string in a column sized with room to grow.
- Verify using the library's verify function, which also compares safely.
- Plan to raise the cost over time by re-hashing at login.
If you already encrypt passwords
Treat it as an incident of design, not a quick patch. Plan to move to hashing: on each successful login, hash the plaintext and replace the encrypted value. For accounts that never log in, set a deadline and force a reset afterward. Rotate and retire the old key once the last encrypted value is gone.
When you do need to recover a credential
If your system must send a credential to another system, such as an API key your app presents to a third party, that is a secret, not a user password. It needs encryption with proper key management, since you must use it. Do not mix the two designs.
Try it yourself
Open the code scan demo and look at how a finding is described. A reversible password column or a fast hash call is the sort of pattern a scan can surface for review.
Click through it at your own pace, or open it full screen.
Safeguard can generate an SBOM and scan your dependencies, so outdated cryptography libraries with known advisories show up in one inventory, and policies can gate a build on them. A free scan is at gold.safeguard.sh/scan.
Quick check
Is SHA-256 with a salt good enough?
It is better than nothing, but it is still fast. Use a password hashing algorithm.
Does a long password make the algorithm choice less important?
Length helps, but the stored hash is what an attacker targets after a breach. Both matter.
Sources
Last reviewed: 19 October 2026.
