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