Why stolen password hashes still matter
Slow password hashing and unique salts reduce guessing risk, but they do not make a stolen database harmless.
Originally posted · Published here · 1 source · Resume reading
A properly designed application stores password hashes rather than plaintext passwords. If those records are stolen, an attacker can still try candidate passwords and compare the results. The choice of hashing method affects how expensive those guesses become [1].
Use a password-hashing function
OWASP recommends dedicated, slow password-hashing algorithms and a unique salt for each password. It advises against using a fast general-purpose hash such as SHA-256 by itself for password storage [1].
A salt prevents identical passwords from automatically producing identical stored hashes and frustrates precomputed lookup tables. It is not a substitute for an appropriately configured password-hashing algorithm.
Check the implementation you actually run
Use the password-storage facilities provided by a maintained authentication library. Confirm the algorithm and parameters, and benchmark verification under realistic load before changing them [1].
Our post described a common breach pattern. It should not be read as a guarantee that every compromised service stored passwords safely. Some incidents involve plaintext, weak hashes or other sensitive records.
For incident response, identify which data was exposed and follow the affected service's verified instructions. The presence of hashes is one part of that assessment, not proof that users face no risk.
Keep this guide
Filed under Security
Sources
- OWASP: Password Storage Cheat Sheetcheatsheetseries.owasp.org