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.

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!