Secure Password Storage & Management
0 likes169 views
This document provides recommendations for password security best practices including: 1) Using cryptographically strong hashing and salts to securely store passwords and make them difficult to crack or recover. It recommends algorithms like PBKDF2, SCRYPT, and HMAC. 2) Implementing multi-factor authentication (MFA) to provide an additional layer of security beyond just a password. Factors could include email, SMS, mobile apps, or dedicated hardware tokens. 3) Designing "forgot password" and account recovery flows that rely on out-of-band verification like identity questions, randomly generated tokens, and enforcing lockout policies to securely reset passwords without compromising accounts.
![Disable Browser Autocomplete
<form AUTOCOMPLETE="off">
<input AUTOCOMPLETE="off">
Only send passwords over HTTPS POST
Do not display passwords in browser
Input type=password
Store password based on need
Use a salt (de-duplication)
SCRYPT/PBKDF2 (slow, performance hit, easy)
HMAC (requires good key storage, tough)
[2][2]Password Defenses](https://image.slidesharecdn.com/2015-03-07-secure-password-storage-160725044222/85/Secure-Password-Storage-Management-3-320.jpg)
![2) Use a Cryptographically strong
credential-specific salt
•) Protect ([salt] + [password]);
•) Use a 32 char / 64 char salt
(may depend on protection function)
•) Do not depend on hiding / splitting /
otherwise obscuring the salt
Password Storage](https://image.slidesharecdn.com/2015-03-07-secure-password-storage-160725044222/85/Secure-Password-Storage-Management-8-320.jpg)
![3) Impose difficult verification on attacker
ONLY
•) HMAC-SHA256 ([private key], [salt] + [password])
•) Protect the key as any private key
•) Store key outside the credential store (HSM?)
•) Improvement over (solely) salted schemes; relies on
proper key creation & management
Password Storage](https://image.slidesharecdn.com/2015-03-07-secure-password-storage-160725044222/85/Secure-Password-Storage-Management-9-320.jpg)
![4) Impose difficult verification on both
(impacts attacker more than defender)
•) pbkdf2([salt] + [password], c=10,000,000);
•) PBKDF2 when FIPS certification or
enterprise support on many platforms
required
•) Scrypt when resisting hardware accelerated
attacks is more important
Password Storage](https://image.slidesharecdn.com/2015-03-07-secure-password-storage-160725044222/85/Secure-Password-Storage-Management-10-320.jpg)
Secure Password Storage & Management
- 1. 1 Many thanks (content & inspiration) to: Jim Manico
- 2. OWASP Top 10 - 2013
- 3. Disable Browser Autocomplete <form AUTOCOMPLETE="off"> <input AUTOCOMPLETE="off"> Only send passwords over HTTPS POST Do not display passwords in browser Input type=password Store password based on need Use a salt (de-duplication) SCRYPT/PBKDF2 (slow, performance hit, easy) HMAC (requires good key storage, tough) [2][2]Password Defenses
- 4. 1) Do not limit the type of characters or length* of user password •) Limiting passwords to protect against injection is doomed to failure •) Use proper encoder and other defenses described instead Password Storage
- 5. Simple Most Common→ ● Plaintext passwords – Vulnerable to: DB Dumps Admins
- 6. Simple Most Common→ ● Encoding != Hashing – Many (mis)guides out there
- 7. Simple Most Common→ ● Encryption is not good enough – Reversible – Many “beginner's guides” use such examples – Avoiding giving the links here (out of context references!)
- 8. 2) Use a Cryptographically strong credential-specific salt •) Protect ([salt] + [password]); •) Use a 32 char / 64 char salt (may depend on protection function) •) Do not depend on hiding / splitting / otherwise obscuring the salt Password Storage
- 9. 3) Impose difficult verification on attacker ONLY •) HMAC-SHA256 ([private key], [salt] + [password]) •) Protect the key as any private key •) Store key outside the credential store (HSM?) •) Improvement over (solely) salted schemes; relies on proper key creation & management Password Storage
- 10. 4) Impose difficult verification on both (impacts attacker more than defender) •) pbkdf2([salt] + [password], c=10,000,000); •) PBKDF2 when FIPS certification or enterprise support on many platforms required •) Scrypt when resisting hardware accelerated attacks is more important Password Storage
- 11. Single Sign On Considerations ● Enterprise integration scenarios – Highly recommended (secure it once) ● General principles – Login screen must be served directly by the IdM system – IdM system authenticates and issues “a token” (to client) – IdM system maintains strong password policy – Relying Parties (applications) receive token from client – RPs verify token validity with IdM before starting a session – RPs check authorization separately
- 12. Basic MFA Considerations 12 • Where do you send the token? – Email (worst – yet, better than none!) – SMS (ok) – Mobile native app (good) – Dedicated token (great) – Printed Tokens (interesting) • How do you handle thick clients? – Email services, for example – Dedicated and strong per-app passwords
- 13. Basic MFA Considerations 13 • How do you handle unavailable MFA devices? – Printed back-up codes – Fallback mechanism (like email) – Call-in center • How do you handle mobile apps? – When is MFA not useful in mobile app scenarios?
- 14. “Forgot Password” design Require identity questions Last name, account number, email, DOB Enforce lockout policy Ask one or more good security questions https://www.owasp.org/index.php/Choosing_and_Using_Security_Ques tions_Cheat_Sheet Send the user a randomly generated token via out-of-band email, SMS or hardware / software token generator Verify code in same web session Enforce lockout policy Change password Enforce password policy
- 15. Thank you!