Securing Passwords against Dictionary Attacks

1
Securing Passwords against Dictionary Attacks

• Benny Pinkas, Tomas Sander
• HP Labs
• (most work done at STAR Lab, Intertrust)

2
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)

3
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?

4
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

5
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

6
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.

7
Countermeasures against offline dictionary attacks
Delayed answer
Account locked
8
Global Password Attack Countering the
countermeasurs
Pipelining guesses High throughput
Use different usernames - no locking
9
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.

10
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.

11
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.

12
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
13
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).

14
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?

15
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 isnt too easy.

16
Simple method
(id,pwd) valid, and RTT answer is correct
Otherwise
17
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 Users experience is more annoying
• Scalability server must generate many RTTs (one
  per login attempt).

18
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).

19
Improved Authentication Method
cookie, id, pwd

• If password is correct
• Cookie indicates previous successful login to
  same account?
• Yes
• No

Grant access
RTT?

• Solution?
• Yes Grant
• No Deny!

• If password is incorrect

With prob 90 deny access With prob p10 ask for
an RTT and then deny access
20
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.

21
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)

22
Security - example

• Parameters N106 passwords, 1000 possible
  answers for RTT, p10.
• 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.

23
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

24
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 L100
  unsuccessful login attempts

25
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

26
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.