Securing Passwords against Dictionary Attacks
Download
Report
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.