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
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
Password Protocol
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, IDsite)
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) gy, gxy
H (P) gx
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
http://crypto.stanford.edu/PwdHash
User Interface
Password Protocol
Applet/Script
Browser
Plu
g-i
n
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)
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
Password Protocol
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