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 —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?

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 PasswordProtocol Basic Model: User Authenticates with a Password

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!

P 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) H (P, R, ID site ) R

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) g y, g xy H (P) g x

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?

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? A Closer Look User Interface Password Protocol Applet/ Script Browser

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

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!

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

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 User Interface Password Protocol Applet/ Script Browser Plug-in

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, ID Bad ), needs Hash (P, ID Good ) 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)

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

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

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 PasswordProtocol

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