Transcript Securing Passwords against Dictionary Attacks

Securing Passwords against
Dictionary Attacks
Benny Pinkas, Tomas Sander
HP Labs
(most work done at STAR Lab, Intertrust)
In this talk
• Online dictionary attacks against passwords
• Current countermeasures are insufficient and
introduce risks
• A solution using Reverse Turing Tests
• Prevent online dictionary attacks, while
preserving the advantages of using passwords
(low costs, portability, user friendliness…)
Motivation
• Passwords are the most common
authentication method
• They are inherently insecure
• How can a password based authentication
system be secured against online
dictionary attacks?
Insecurity of Passwords
• Human generated passwords
• Come from a small domain
• Easy to guess – dictionary attacks
• Stronger passwords
• Computer generated or verified
• Not user friendly
• Hard to remember
Previous suggestions: securing
passwords against online attacks
• Enterprise:
– hardware tokens. (Cost? Usability?)
– Server defined passwords. (Usability?)
• Consumer:
– Key stroke timing [Bell Labs] (Reliability?)
– Graphical passwords [Microsoft, Berkeley]
(Usability?)
None of these methods is as popular as plain
passwords
Possible attacks on passwords
• Eavesdropping. (Solution: encrypt the
channel, e.g. using SSL or SSH.)
• Offline dictionary attacks. (Solution:
limit access to password file, use salt.)
• Online dictionary attacks: Attacker
guesses a username/password pair and
tries to login.
Countermeasures against
offline dictionary attacks
Username / pwd-1
Answer 1 (No)
Username / pwd-2
Delayed answer
Answer 2 (No)
Username / pwd-5
Answer 5 (No)
Account locked
Global Password Attack:
Countering the countermeasurs
Username-1 / pwd-1
Pipelining guesses:
High throughput
Answer 1
Username-2 / pwd-2
Answer 2
Use different
usernames no locking
Username-100 / pwd-100
Answer 100
Risks of locking accounts
• eBay experiences dictionary attacks, but
does not implement account locking.
• Denial of service attacks: To lock a user,
try to login into his account with random
passwords. (auctions, corporates…)
• Customer service costs: Users whose
accounts are locked call a customer
service center – cost is $20-50 per call.
Using Pricing via Processing [DN]
• Idea: each login attempt must be
accompanied by H(username,pwd,t,r) s.t.
20 least significant bits are 0.
• Negligible overhead for a single request.
• A dictionary attack is slowed by a factor
of 220 (must find r for every pwd guess).
• Implementation problems:
• Clients must use a special software.
• Legitimate user with a slow machine.
Our Approach
• Legitimate logins – done by humans.
Dictionary attacks – run by programs.
• Login attempts must be accompanied
by a computation that is easy for
humans and hard for programs.
• Other requirements: Little impact on
usability, portability, no additional
hardware, easy implementation and
integration.
Reverse Turing Test (RTT)
Verifies “human in the loop”. A challenge from a domain
in which humans excel and computers fail.
Please type the following word:
Properties of Reverse Turing
Tests (RTT, Captcha, ATT)
• Automated generation and
verification.
• Easy for humans.
• Hard for computer programs.
• Small probability of guessing the
answer (I.e. not a yes/no answer).
Reverse Turing Tests (RTT)
• Suggested by Moni Naor in 1996.
• Captcha project, CMU.
http://www.captcha.net
• Used to prevent automated programs
from accessing different features of
web sites (Yahoo!, Paypal, AltaVista).
• Possible accessibility problems?
Security of RTTs
• Alta Vista: # of url submissions down by
90% after RTT were required.
• Pessimal print – “…RTTs are, and will be,
hard for OCR programs” [CBF].
• Unfortunately, simple RTTs (Yahoo!’s),
displaying English text, can be broken
with high probability [MM2002].
• There will be an arms race. We only need
that breaking RTTs isn’t too easy.
Simple method
I want to login
RTT
id, pwd, RTT answer
Welcome!
Go away!
(id,pwd) valid, and
RTT answer is correct
Otherwise
Properties
• Securitya:
– Each password guess requires an RTT.
– Hard to guess RTT answer.
– Password space of size N requires
adversary to answer N RTTs
• Usability: User’s experience is more annoying
• Scalability: server must generate many RTTs
(one per login attempt).
Improved Authentication Method
• Each user typically uses a limited set
of computers.
• Dictionary attacks originate from
other computers.
• Servers can identify machines (e.g.
using cookies or ip addresses).
Improved Authentication Method
cookie, id, pwd
• If password is correct:
– Cookie indicates previous
successful login to same
account?
Grant access
• Yes
RTT?
• No
Solution?
• If password is incorrect:
• Yes: Grant
• No: Deny!
With prob 90% deny access
With prob p=10% ask for an RTT
and then deny access
Properties
• Usabilitya- user has to answer RTT
– In the first login from a new
computer
– If entered wrong password
• Scalabilitya: Server generates
RTTs only for 10% of incorrect login
attempts.
Security
• User must receive identical feedback if,
– (id,pwd) pair is correct but RTT is required
– (id,pwd) pair is incorrect and RTT is
required
• Attacker can easily identify a set of pN
candidate passwords.
• To check these passwords, has to “pay”
with an RTT answer per password.
• (We can also protect against cookie
theft)
Security - example
• Parameters: N=106 passwords, 1000
possible answers for RTT, p=10%.
• Attacks:
– Attacker guesses RTT answer: succeeds
with prob 10-8.
– Attacker breaks RTT in 3 seconds
(automatically or using humans):
expected to invest 42 hours per account.
And if RTT is broken…
• Identify a successful attack:
– Monitor fraction of login attempts that solve
the RTT but fail in entering password.
– Set alarm when this fraction increases.
• Countermeasures:
– Increase p (fraction of logins requiring RTT).
– Switch to an RTT from a different domain.
– Notify administrator
Implications wrt Account locking
• Common practice today: lock account
after L unsuccessful login attempts.
• Risks: Denial of service, service calls.
• Assume: A secure RTT with 1000 possible
answers, RTT needed for 10% of pwd
guesses.
• Pwd space increases by a factor of 100.
• Therefore, can lock accounts after L*100
unsuccessful login attempts…
Benefits to server
• Better security against break-ins.
• Visible security measures, but with
few usability effects.
• Easy implementation and integration.
• Less account locking
– Less denial of service attacks – important
for corporates, auctions,…
– Save money - less customer support calls
Scores wrt Different Criteria
• Availability and portability: account
can be accessed from everywhere.
• User friendliness: easy learning curve
• Robustness: less account locking
• Low implementation and operation
costs
• Passwords score well.
• Our solution scores well, and provides
better security.