Authentication and passwords

Transcription

1 Authentication and passwords

2 Passwords

3 The Key Idea Prover sends a password to a Verifier. The channel must be private If an attacker obtains a user s password, he can authenticate as her. Passwords must be hard to guess But easy to remember, so that they don t have to be written down. We need to balance security and usability. E.g., Passwords should be changed frequently But this change shouldn t be mandatory

4 Issues with passwords Need to examine: Choosing the password And how to set and change it Storing the password on each side cryptography software / hardware security Using/typing the password: *** vs shoulder surfing Transmitting the password encrypted in some way? not guaranteed to be sufficient

5 Users have the right to be bad. Bad User?

6 Attacks Taxonomy Discovering shoulder surfing device malware keyboard logger eavesdropping / sniffing from network stealing from a server spoofing (fake login page) Guessing and verifying the guess online offline

7 Password guessing Online guessing Attacker attempts to access system and submits a guess of the password Attacker can be thwarted by rate limiting Offline guessing Attacker checks a guess of the password against captured data Attacker does checking in private; cannot be thwarted by rate limiting Target: against one particular user many users, target any one: can be easier! target many users

8 Password strength

9

10 Entropy of a Source Let X be a random variable (with a finite or infinite number of possible outcomes x i ). The entropy of X [Shannon] is: H(X) = - Σ x Pr[X=x] log 2 Pr[X=x] Suppose x i has probability p i of occurring. Then H(X) = - Σ i p i log 2 p i = Σ i p i log 2 (1/p i )

11 Let X be a toss of a fair coin x1 = heads, p1 = 0.5 Examples x2 = tails, p2 = 0.5 H(X) = log 2 (0.5) log 2 (0.5) = 1 Thus, exactly as one would expect, a fair coin toss carries exactly one bit of information. Let X be a toss of a biased coin x1 = heads, p1 = 0.3 x2 = tails, p2 = 0.7 H(X) = log 2 (0.3) 0.7 log 2 (0.7) = 0.88 So a biased coin carries less information (it s more predictable). By the same calculation, a 0.01, 0.99 biased coin carries 0.02 bits of information.

12 Application to passwords Let X be a password selected from 8 character strings formed from the alphabet A-Z a-z 0-9!@$%^&*()_-=+\ ;., Say the alphabet has = 80 characters Passwords have length 8, so there are 8 80 = possibilities. The entropy is 240 bits. Σ (1/2 240 ) log 2 (2 240 ) = 240. Sounds great but that s assuming every password is as likely as every other one. We know password123, letmein are much more likely And j&fr}5=x very unlikely. So what is the true entropy in typical password scenarios?

13

14 Approximating real-life passwords Let s assume that 20% of the users pick a very bad password Paswords like password, pa$$w0rd, and each of the (say) 20 other variations Also words like letmein, , qwerty,, and their variations Say there are 200 similar passwords. Another 30% of the users chose dictionary words with a number at the end, like laptop3 Say there are 1000 words, 10 numbers = such passwords Another 40% of them did it slightly better: lovelife^$& Say there are 1000 words, 1000 decorations = 10 6 such passwords That leaves a remaining 10%... 4% picked from 10 8 passwords 4% picked from passwords 2% picked from the remaining such passwords

15 Calculating the entropy There are 200 passwords each with probability 0.2*1/200 Σ 200 -(0.2 * 1/200) log 2 (0.2 * 1/200) = 1.99 And passwords, each with prob 0.3*1/10000 Σ (0.3 * 1/10000) log 2 (0.3 * 1/10000) = passwords, each with prob 0.4 * 1/10 6 Σ (0.4 * 1/10 6 ) log 2 (0.4 * 1/10 6 ) = passwords, each with prob 0.04 * 1/10 8 Σ (0.04 * 1/10 8 ) log 2 (0.04 * 1/10 8 ) = passwords, each with prob 0.04 * 1/10 20 Σ (0.04 * 1/10 20 ) log 2 (0.04 * 1/10 20 ) = passwords, each with prob 0.02 * 1/10 72 Σ (0.02 * 1/10 72 ) log 2 (0.02 * 1/10 72 ) = 4.8 Total: 24 bits of entropy on average And check that our probabilities add up to 1.

16 Battery horse staple Let s say you use a dictionary of 90,000 words /usr/share/dict/words has 99,171 words on my system Computer chose 4 words uniformly at random Like correct battery horse staple This gives us possibilities, that s possibilities So it s about 66 bits of entropy Let s calculate the entropy with the log formula There are passwords, each with probability 1/ Σ (1/ ) log 2 (1/ ) = 65.8 That s great. But how usable is it? Say you have 40 passwords to remember...

17 User-chosen vs system-generated? 99% of systems including most banks allow people to chose their passwords. This makes them much less secure. lower entropy in general even for security-aware users, humans are UNABLE to generate really random numbers; entropy is just lower But hard to make system-generated passwords memorable.

18 Core password problem Impossible situation for humans: Secure => uniformly random (chosen by machine) => not memorable by humans Passwords must be different for every service. Usually implies compromise betw. memorable and random Passwords are chosen by the user (memorable) But aim to be as random as possible, e.g. Passwords must have mix of A-Z a-z 0-9 $%^&*() Must change every 6 months, must be different from previously chosen 10 pwds Increasingly popular: password managers Passwords chosen by machine, stored in pwd manager User just remembers one password, to unlock the manager Problem: single point of failure, from both security and availability points of view.

19 Secondary passwords (pwd recovery service) Two problems: Usually less secure, backdoor entry point Sarah Palin hack: Yahoo account of USA vice presidential candidate was accessed by David Kernell in Sept 2008, who looked up bio details including high school and birthdate and used Yahoo s password recovery service. Legitimate users fail to pass. Most these questions such as the name of your first pet do or your fist car do not have a unique answer problems with spelling, capital letters etc. users may deliberately put incorrect information anyway

20 Password Storage

21 Password Storage and Verification How to store a password p? Method 1: store p. VERY BAD! Unnecessary point of failure. Attacker might obtain all the passwords. If a website is able to remind you of your pwd, it s storing them: rubbish website. Not needed! Key concept: OWF = One-Way Function.

22 Password Storage and Verification Method 2: store h(p). Better but Brute force attacks possible, even though h is a OWF. If an attacker obtains all the password hashes, it can try to guess them, and check the guesses offline. Simple use of a OWF does protect strong passwords, but it doesn t adequately protect weak ones.

23 Password Storage and Verification Method 2: store h(p). This method allows an attacker to guess a password and verify it against all the users in one go For each guessed p, just check if h(p) is in the password file.

24 Password Storage and Verification Method 3: Key idea: make sure identical passwords are stored differently. Example 1: store h(name, p). Example 2: store h(salt, p), salt. With salt being a random shadow ID for this user. Unix originally stored h(p) in readable /etc/passwd Now it stores h(salt,p),p in /etc/shadow, readable only by root: defence in depth now cannot relate passwords from different users, removes the faster dictionary attack form the last slide

25 So is it better to store: Method 3A: store h(name, machine ID, salt, password), salt?

26 Slow hash functions Instead of using a plain hash function, one can use one that is deliberately slow This slows down the attacker who is doing offline guessing. It adds small cost to the verification process hopefully negligible. PBKDF2 (standardised in 2000) iterates 1000 times (or 10000). Unfortunately, can be done very fast on ASICs or GPUs bcrypt (1999) needs more RAM, resists better. scrypt can use arbitrarily large amounts of memory, resists better

27 Lots of password leaks In June 2012 a file containing over six million password hashes which allegedly originated from LinkedIn was widely circulated over the Internet. Hashes were not salted. Later, hackers found out lots of passwords using rainbow tables and dictionary attacks. Many cracked passwords contained "linked" or even "linkedin ; for example "lawrencelinkedin". Even passwords such as "parikh ", "a06v1203n08" and "376417miata? " have already been cracked

28 Ashley Madison In July 2015, a group calling itself The Impact Team stole the user data of Ashley Madison, a website aiming to enable extramarital affairs. Passwords were salted, and hashed with bcrypt. This means strong passwords are safe, but weak ones can still be brute-forced. Five days of cracking revealed 4000 passwords out of 36M (1%) (202), password (105), (99), qwerty (32), (31), ashley (28), baseball (27), etc. Caveat: maybe some users picked weak passwords because they entered throw-away data

29 Case study: Firefox password mgt (see other slides)

30 Limited disclosure schemes Used by many banks, please type digits 1,3,4 and the last. * * * * Addresses: malware on client; shoulder surfing; keyboard logger Does not address: theft of password file from server Quiz: if failed, should the system ask the same or different subset?

31 Limited disclosure schemes How to store these passwords? Store in the usual way, h(p,salt),salt? Doesn t work! Store individual characters, h(c1,salt1),h(c2,salt2),? Insecure! Something else?

32 Key properties: One-Time Passwords (OTP) The password is changed each time The attacker cannot know it in advance, real-time man-in-middle attacks remain possible

33 Lamport OTP Scheme Based on OWF. Use hash chains, go backwards. Let x 1 =h(x), x 2 =h(x 1 ),, x 1000 =h(x 999 ). Store x 1000 on the server. Small storage. Fast. Go backwards: passwords are x 999, then x 998, then Each x i allows to log-in only once. If user submits p, server checks if h(p)=x. If true, then x:=p, and login is accepted. User keeps a sheet with x 999, x 998, x 997, x 996. Problem: can be photocopied and the user still has it, naively thinking it is secure

34 => PC login Time-synchronized OTP

35 Time-synchronized OTP Code is fixed for s. Window of opportunity: 30 s, second session possible connected from another location

36 Challenge-Response Protocols

37 K Challenge is a random nonce K A random B A, MAC K (random B, B) B

38 K Challenge is time or counter K A A, tc, MAC K (tc, B) B can also use a block or stream cipher, used as a MAC

39 Counters, nonces, timestamps Challenge = random nonce (best solution) Counter/sequence number as a static challenge E.g., wireless car key sends id, MAC K (id, counter), where k shared between key and car Time as a challenge difficult to make secure Need reliable, synchronised clocks Challenge to make granularity small enough

40 Unilateral vs bilateral authentication Unilateral auth is historically very popular. Examples: password -> login SIM card -> GSM base station (fixed in 3G) offline bank card transactions -> Point of Sale terminal Problems: login page spoofing etc. false GSM base stations false ATMs

41 Bilateral authentication Really important on the web, to try to prevent phishing attacks TLS Problems: Key certification