Passwords Don’t Get No Respect – Or, How to Make the Most of Weak Shared Secrets

1. Passwords Don’t Get No Respect – Or, How to Make the Most of Weak Shared Secrets Burt Kaliski, RSA Laboratories DIMACS Workshop on Theft in E-CommerceApril 14, 2005

2. Introduction • Passwords have remained an authentication factor of choice for the majority of users since the 1970s • And other forms of “weak” secrets are becoming more common, e.g., “life” questions • Yet password protocols haven’t advanced much in practice, despite considerable research over three decades • Passwords still typically sent directly to the site that requests them! • As a result, passwords are at risk of theft, e.g., phishing attacks • Why haven’t passwords gotten more “respect”, and what can the industry do about it?

3. Password Protocol Basic Model: User Authenticates with a Password • User wants to connect to a Web site • User provides a password to a client computer • Client runs a password protocol with the site • User doesn’t have a trusted device; client doesn’t have persistent storage for secrets

4. Informal Security Goals • Authenticate the user to the Web site • Don’t reveal the password to an outsider • Authenticate the Web site to the user? • Don’t reveal the password to the Web site!

5. Simple Password Protocols • Password only: • Client sends password directly to site • Challenge-response • Site sends challenge, client sends hash of challenge, site identifier, and password • Extension: site returns another hash for mutual authentication • In both cases, the site can get the password (eventually) P R H (P, R, IDsite)

6. Password-Authenticated Key Agreement • EKE • SPEKE • SRP • SNAPI • AuthA • PAK • … and a host of others have been produced by the research community over the past 15 years • With these protocols, the site can’t get the password if it doesn’t already know it, and authentication is typically mutual H (P)gx H (P)gy, gxy

7. Yet, the State of the Art Hasn’t Changed Much • Despite all this work protocols, passwords are still typically sent directly to a Web site using the simplest protocol • May be tunneled within server-authenticated SSL/TLS to protect against outsiders • But if the site is the wrong one, password is compromised • And no direct feedback to the user about whether the site is good or bad • Why?

8. Protocol Browser Password Applet/ Script A Closer Look • Protocol typically implemented by application code within the client, e.g. an applet or script running in a browser • “Bad” applications can just include the wrong protocol in order to get the password • Even if the right protocol is “built in” to the browser, how can you be sure the application is actually using it? User Interface

9. Convenience vs. Security • Web application design has aimed for convenience, not security • As a result, the user name / password form has become the standard authentication interface • A password hashing protocol is built into browser – but interface is less convenient, and it isn’t used much • Server authentication is presumed to address the “trust” issue, but the user interface is inconvenient

10. Larger Factors to Consider • Meanwhile, smart cards, one-time password tokens, etc. have gotten much of the respect for users interested in security • Passwords have just gotten stronger password policies – which has perhaps made them harder to use • But overall, the 1970s model where the system is trusted but the user is suspect has prevailed • Users are in the habit of trusting any form that asks for a password • They don’t have the tools to distinguish good ones from bad ones!

11. Strengthening the Interface • Browsers need to have a stronger protocol built in that has a convenient interface • … and users need a way to ensure that the protocol is actually used, even by a bad application • Challenging with today’s systems, since bad application can simulate appearance of good one • Keystroke loggers and other malware present another set of threats – focus here on application code within the browser

12. Protocol Browser Password Applet/ Script Example: Stanford PwdHash Plug-In(Ross et al., USENIX Security 2005) • PwdHash browser plug-in detects when user is entering a password, and hashes it before the application receives it • Plug-in can filter content for password fields, or user can signal plug-in with a reserved control sequence (F2 key in this case) • The hashed password is thus sent to the Web site, rather than the password itself http://crypto.stanford.edu/PwdHash User Interface Plug-in

13. What Do You Hash With? • Something about a good site that a bad Web site can’t easily simulate, without some effort • Examples: • IP address • URL • public key • Bad site gets Hash (P, IDBad), needs Hash (P, IDGood) • Brute-force password searching is an economic deterrent to attacker, given availability of unhashed passwords elsewhere • slow hashing and salt can further strengthen protection; pepper can also help with slower clients [Hellman, PTO ‘99] (see also EAP-POTP spec., Nyström ’05)

14. Extension: Mutual Authentication • Hashing doesn’t provide any feedback about whether site is good or bad • Bad Web site could just say “Password confirmed” and lure user into disclosing other personal information • A mutual authentication protocol is needed for higher assurance • Plug-in (or operating system!) should detect when user is entering a password, and run protocol before returning control to application • As a lightweight starting point, plug-in could wait for application to return its own password hash, and tell user if it’s correct

15. Towards Trustworthy Interfaces: A Password-Protection Module • The plug-in or comparable operating system component is effectively a password protection module that assures the user that the right protocol is actually being used • Hashing, or any of the more sophisticated versions • Reserved control sequence is a convenient and secure way to activate such a module • CTRL-ALT-DEL is the analogy for client and network login • The module doesn’t need to change the user interface dramatically; it just needs to take control • Presenting feedback about mutual authentication in a way that can’t be simulated remains a little challenging

16. Password Protocol Conclusions • If passwords continue to be an authenticator of choice, then users don’t just need more password protocols • Instead, they need more trustworthy interfaces that ensure the protocols are actually used • A more trustworthy interface also protects stronger forms of authentication; the infrastructure improvements benefit everyone

17. TIPPI Workshop • Dan Boneh and I are organizing a workshop on this topic: • Submission deadline May 15 • For more information: http://crypto.stanford.edu/TIPPI • TIPPI 2005: 1st Workshop on Trustworthy Interfaces for Passwords and Personal Information • June 13, 2005Stanford University