When an AI proposes a fix for weak password storage, check four things: the algorithm is a slow password hashing function, each password gets a unique salt, the cost settings meet current guidance, and existing hashes have a migration path. Swapping one fast hash for another fast hash is not a fix.
What current guidance says
The OWASP Password Storage Cheat Sheet says passwords must never be stored in plain text, and should be protected with strong, slow hashing algorithms such as Argon2id, bcrypt or PBKDF2. A unique salt is added to each password so precomputed lookup tables do not help an attacker. Fast hashes such as SHA-256 are not suitable for password storage because they allow huge numbers of guesses.
At the time of review, the cheat sheet recommends Argon2id with at least 19 MiB of memory, an iteration count of 2 and one degree of parallelism. If Argon2id is not available, it names scrypt with specific minimum parameters. For legacy systems using bcrypt, it recommends a work factor of 10 or more and notes a 72 byte password limit. Where FIPS-140 compliance is required, it names PBKDF2 with a work factor of 600,000 or more. Guidance like this changes, so open the current page rather than trusting this summary.
Checklist for the suggested change
| Check | Good sign | Problem sign |
|---|---|---|
| Algorithm | A password hashing function from a maintained library | MD5, SHA-1 or a plain SHA-2 hash, even if salted |
| Salt | Generated per password, handled by the library | One global constant in the source |
| Cost | Parameters set to current guidance and configurable | Defaults copied from an old tutorial |
| Library | A well known, maintained package that exists | A package name the model may have invented |
| Migration | Plan for hashes already stored | Code that breaks every existing login |
The migration question people forget
Changing the function in the code does not change the rows already in your database. Common approaches, which you should confirm fit your system, are to rehash at the next successful login, or to wrap old hashes inside the new function and upgrade them over time. An AI diff that updates registration but not login verification will either lock users out or leave old hashes unchecked.
Read the login path as carefully as the signup path. Also check that comparison of hashes is done by the library's verify function, not by hand.
Verify the package
AI suggested packages should be checked for existence and maintenance before install. OWASP's guidance on secure coding with AI warns that assistants frequently suggest package names that do not exist, and that attackers may register those names. Check the registry page, age and maintainers.
Test it
- A new account can sign in.
- An old account can sign in and gets upgraded.
- A wrong password fails.
- The stored value is not the password and not reversible.
Safeguard's dependency scanning can flag vulnerable packages and its fix pull requests are off by default. Choosing the hashing parameters remains an engineering decision for your team.
Quick check
Is salted SHA-256 acceptable for passwords?
OWASP says fast hashes such as SHA-256 are not suitable for password storage. Use a slow function designed for passwords.
Should the AI pick the work factor?
It can suggest one, but compare it to the current OWASP page and test login latency in your own environment.
Sources
Last reviewed: 19 October 2026.
