1 / 18

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

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-Commerce April 14, 2005. Introduction. Passwords have remained an authentication factor of choice for the majority of users since the 1970s

fabian
Download Presentation

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

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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

More Related