Securing Passwords against Dictionary Attacks Benny Pinkas Tomas

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 • e. Bay 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, Alta. Vista). • 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 [MM 2002]. • 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 p. N candidate passwords. • To check these passwords, has to “pay” with an RTT answer 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$

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.