A Convenient Method for Securely Managing Passwords

1. A Convenient Method for Securely Managing Passwords J. Alex Halderman Princeton Brent Waters Stanford Edward W. Felten Princeton

2. ****ing Passwords! • Web site password overload Generating, keeping secret, and recalling passwords for scores of sites • Leads to insecure coping techniques • Writing passwords down • Reusing same passwords • Difficult to enforce better behavior We need to make password security easy

3. In This Talk • Approaches to password management • Our construction and its security • Comparison with other techniques • Demonstration of our implementation • Future work and conclusions

4. Approaches to Password Mgmt • Local encrypted storage e.g., Password Safe (1998) • Cumbersome to access from multiple locations • Centralized remote authentication e.g., Microsoft Passport (1999) • Needs server-side changes, trusted third party • Cryptographic password generation e.g., LPWA (1997), PwdHash (2004), our scheme (2004)

5. Password Generators • E.g.: LPWA, PwdHash • Client software derives individual site passwords using deterministic one-way function • Users sets all site passwords to function output • Only need to remember master password to recreate all site passwords—highly transportable! Master Password “amazon.com” Hash() “wrbPzdqS” Use as your Amazon password A simple idea, but hard to get right!

6. Stealing the Master Password Password Guess “spot” “yahoo.com” “lassie” “rover” “spot” “fido” Hash() “RWwsYlTi” “H2VeusSq” “CJPZfAKx” “LZIniBNd” amazon.com  wrbPzdqS gmail.com  obIDmogl citibank.com  sX4rLlO1 == =? “LZIniBNd” “LZIniBNd” Adversary learns password from low-security site Dictionary attack to learn master password Can access all otherpassword-managedsites Easy to execute because scheme use fast hashes

7. Thwarting Brute Force Attacks attack cost = ½ × dictionary size × cost per guess • Hard to increase dictionary size User habits hard to change, limits on human memory • Increase cost per guess by using slower hash • Used elsewhere to protect password verification routines (UNIX crypt) • Our approach: iterated hash • Security vs. usability tradeoff User has to wait too! — Cache intermediate results

8. Our Construction Master password “MyD06ReX” User identity “jhalderm@princeton.edu” Initialization Phase (k1 >> k2) Hk1() Local Cache Target site “amazon.com” Hk2() Master password (again) Generation Phase Mapping User’s site passwordfor “amazon.com” “wrb8zdqS”

9. Security Analysis Four attack scenarios: • No information • Stolen site password • Stolen cache data • Stolen cache + site password Primary concern is offline attacks.  Increasing external difficulty ? ? ?

10. Security of Our Scheme

11. Relative Attack Resistance

12. Equivalent Password Length ********* ******** ****

13. Password Multiplier • Extension for Mozilla Firefox Windows, Mac OS X, and Linux • Tightly integrated with browser Double-click any password field to fill in • Balanced security and convenience • Initialization — 108 iterations, ~100 seconds(Onlyonce per installation) • Password generation — 105 iterations, ~0.1 secs(Before every password operation)

14. Password Multiplier — Demo

15. Future Improvements • Flexible password formatting Cope with sites that require numbers, punctuation, special patterns • Easier password changes Manually and at regular intervals • Improved anti-spoofing Adopt techniques from PwdHash • Port to Internet Explorer, others Require additional “state”

16. Summary — Our scheme: • Provides password access from anywhere our software can be executed • Asks user to remember only one short password • Requires no server-side changes • Does not require trusting a third-party service • Nearly as secure as independent random pwds • Likely much more secure than what you do now • Is practical, available today, and free http://www.cs.princeton.edu/~jhalderm/projects/password/

17. A Convenient Method for Securely Managing Passwords J. Alex Halderman Princeton Brent Waters Stanford Edward W. Felten Princeton