secure password storage & management

Download Secure Password Storage & Management

Post on 18-Feb-2017




0 download

Embed Size (px)


  • 1

    Many thanks (content & inspiration) to:

    Jim Manico

  • OWASP Top 10 - 2013

  • Disable Browser Autocomplete

    Only send passwords over HTTPS POSTDo not display passwords in browserInput 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


    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


    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


    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!

    Slide 1Slide 2Password DefensesPassword Storage in the Real WorldSlide 5Slide 6Slide 7Slide 8Slide 9Slide 10Slide 11Basic MFA ConsiderationsBasic MFA ConsiderationsForgot Password Secure DesignSlide 15