Скачать презентацию Securing Passwords against Dictionary Attacks Benny Pinkas Tomas Скачать презентацию Securing Passwords against Dictionary Attacks Benny Pinkas Tomas

3367a24318dd92078e035c55974f43c1.ppt

  • Количество слайдов: 26

Securing Passwords against Dictionary Attacks Benny Pinkas, Tomas Sander HP Labs (most work done 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 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 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 • 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? 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 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 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 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 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 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 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 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. • 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, 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 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! 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 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. • 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 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 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 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%. • 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 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 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. 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.