secure password storage & management
TRANSCRIPT
1
Many thanks (content & inspiration) to:
Jim Manico
OWASP Top 10 - 2013
Disable Browser Autocomplete<form AUTOCOMPLETE="off"><input AUTOCOMPLETE="off">
Only send passwords over HTTPS POSTDo not display passwords in browser
Input type=password
Store password based on needUse a salt (de-duplication)SCRYPT/PBKDF2 (slow, performance hit, easy)HMAC (requires good key storage, tough)
[2][2]Password Defenses
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
Simple Most Common→
● Plaintext passwords– Vulnerable to:
DB DumpsAdmins
Simple Most Common→
● Encoding != Hashing– Many (mis)guides out there
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!)
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
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
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
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
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
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?
“Forgot Password” design
Require identity questions Last name, account number, email, DOBEnforce 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-bandemail, SMS or hardware / software token generator
Verify code in same web sessionEnforce lockout policy
Change passwordEnforce password policy
Thank you!