Secure Password Storage & Management

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!