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?
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
Password
•
Protocol
User doesn’t have a trusted device; client doesn’t have
persistent storage for secrets
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!
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
•
P
R
H (P, R, IDsite)
In both cases, the site can get the password (eventually)
Password-Authenticated Key Agreement
•
•
•
•
•
•
•
•
EKE
SPEKE
H (P) gx
SRP
SNAPI
H (P) gy, gxy
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
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?
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
Password
•
Browser
User
Interface
Protocol
Applet/
Script
Even if the right protocol is “built in” to the browser, how can
you be sure the application is actually using it?
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
Password
•
User
Interface
Plug-in
— Plug-in can filter content for password fields, or user can signal
plug-in with a reserved control sequence (F2 key in this case)
Browser
Protocol
Applet/
Script
The hashed password is thus sent to the Web site, rather than
the password itself
http://crypto.stanford.edu/PwdHash
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
Password
•
Protocol
A more trustworthy interface also protects stronger forms of
authentication; the infrastructure improvements benefit
everyone
TIPPI Workshop
•
Dan Boneh and I are organizing a workshop on this topic:
TIPPI 2005:
1st Workshop on
Trustworthy Interfaces for Passwords and
Personal Information
June 13, 2005
Stanford University
•
•
Submission deadline May 15
For more information: http://crypto.stanford.edu/TIPPI