Developers: Store Passwords Safely (UK Guide)
Store passwords safely by using modern, salted, one-way password hashing (not reversible encryption), and by setting login controls that slow offline cracking and limit online guessing.
This guide targets UK developers, founders, and small organisations building login systems. It translates OWASP and NIST requirements into an implementable checklist (algorithm choices, parameters, migration, and rate limiting) and anchors the guidance in UK data protection expectations for password-based authentication systems.
Developer checklist
- Hash passwords; never encrypt them.
- Use Argon2id (or scrypt/bcrypt) with appropriate parameters.
- Use a unique salt per password; consider a pepper.
- Rate limit and monitor login attempts.
Hashing vs encryption
Passwords should be hashed, not encrypted. OWASP advises that encryption is reversible—if keys are stolen, attackers can recover passwords. Hashing is one-way; you cannot reverse it to get the original password. Use a suitable key derivation function (KDF) designed for passwords.
Recommended algorithms and baseline parameters
OWASP recommends Argon2id with a stated minimum configuration and provides fallback options (scrypt, bcrypt, PBKDF2). NIST SP 800-63B requires stored passwords to be salted and hashed using a suitable one-way key derivation function. Tune cost factors (memory, iterations) for your environment.
Salts, peppers, and work factors
Use a unique, random salt per password to prevent rainbow-table attacks. Store salts with the hash. A pepper (secret key stored separately) adds another layer. Work factors (iterations, memory) slow offline cracking after a database compromise—increase them as hardware improves.
Prevent online attacks
Rate limit login attempts to slow credential stuffing and brute force. Monitor for unusual patterns. Consider CAPTCHAs or account lockout after repeated failures. See our credential stuffing guide for context.
Password policy and UX
Avoid forced complexity rules that encourage predictable patterns. Allow long passwords. Allow paste (to support password managers). Block known compromised passwords (e.g. via the Have I Been Pwned Pwned Passwords list or API).
Migration and incident response
When upgrading from weak hashes (e.g. MD5, unsalted SHA), rehash on next successful login. Do not store plaintext or reversibly encrypted passwords. If credentials are exposed, invalidate sessions, force password resets, and follow breach notification requirements under UK GDPR.
Frequently asked questions
- Can I encrypt passwords instead of hashing them?
- No—OWASP advises passwords should be hashed, not encrypted, because encryption can be reversed if keys are stolen.
- What does NIST require for stored passwords?
- NIST says stored memorised secrets must be salted and hashed using a suitable one-way key derivation function.
- What's the UK compliance angle?
- ICO guidance frames password systems as a security control protecting personal data and expects "appropriate" measures under UK GDPR security principles.