Protocols for Checking Compromised Credentials Lucy Li Bijeeta Pal - - PowerPoint PPT Presentation

protocols for checking compromised credentials
SMART_READER_LITE
LIVE PREVIEW

Protocols for Checking Compromised Credentials Lucy Li Bijeeta Pal - - PowerPoint PPT Presentation

Protocols for Checking Compromised Credentials Lucy Li Bijeeta Pal Junade Ali Nick Sullivan Cornell Tech Cloudflare Inc. Cornell Tech Cloudflare Inc. Rahul Chatterjee Thomas Ristenpart University of WisconsinMadison Cornell Tech


slide-1
SLIDE 1

Protocols for Checking Compromised Credentials

Lucy Li

Cornell Tech

Bijeeta Pal

Cornell Tech

Thomas Ristenpart

Cornell Tech

Rahul Chatterjee

University of Wisconsin—Madison Cornell Tech

Junade Ali

Cloudflare Inc.

Nick Sullivan

Cloudflare Inc.

slide-2
SLIDE 2

Password breaches

2

Have I Been Pwned: 406 breaches

…and many more

Breach compilation from 2018: 1.4 billion user-password pairs

Leaked Credentials Username Passwords … … lucy@email.com myPassword123 alice@yahoo.com Star246, p4ssw0rd1 … …

slide-3
SLIDE 3

Credential Stuffing

3

lucy@email.com myPassword123

website.com

Leaked Credentials Username Passwords … … lucy@email.com myPassword123 alice@yahoo.com Star246, p4ssw0rd1 … …

Around 40% of users reuse passwords across different websites!

[Das et al. 2014, Pearman et al. 2017]

Credential stuffing is the largest source of account takeover and automated fraud

[Shape Security]

slide-4
SLIDE 4

One way to prevent credential stuffing

4

lucy@email.com myPassword123

website.com

reset password newPassword789 lucy@email.com myPassword123 EXISTS lucy@email.com myPassword123 Leaked Credentials Username Passwords … … lucy@email.com myPassword123 alice@yahoo.com Star246, p4ssw0rd1 … … Leaked Credentials Username Passwords … … lucyli@email.com myPassword123 alice@yahoo.com Star246, p4ssw0rd1 … …

Li Limitations:

  • Hard for websites to keep an up-

to-date copy of credential leaks

  • Don’t want to have copies of

leaked credentials everywhere

slide-5
SLIDE 5

Can we use a third party checker and still preserve privacy of user credentials? Two big initial deployments:

Third Party Checker

5 website.com

lucy@email.com myPassword123 Leaked Credentials Username Passwords … … lucy@email.com myPassword123 alice@yahoo.com Star246, p4ssw0rd1 … …

Third party

EXISTS lucy@email.com myPassword123

Don’t send credentials in the clear to a third party

slide-6
SLIDE 6
  • 1. Formalization of compromised credential checking (C3) protocols

and threat model

  • 2. HIBP and Google Password Checkup leak information about

passwords

  • 3. New C3 protocols that leak less
  • Frequency-smoothing bucketization
  • ID-based bucketization

Our contributions

6

slide-7
SLIDE 7

Compromised Credential Checking Services

7

Leaked Credentials Username Passwords … … lucy@email.com myPassword123 alice@yahoo.com Star246, p4ssw0rd1 … …

website.com

Cl Client C3 C3 Server pw pw OR (u (u, pw) OR

Credential Entity

Client finds out if their credential is in the server’s database

slide-8
SLIDE 8

Threat model

8 Passwords … dog456 abc123 1password23 …

Passwords … dog456 abc123 1password23 …

Client C3 server

1. 1. Pr Protect leaked credential database from malicious client

slide-9
SLIDE 9

1. Protect leaked credential database from malicious client

2. 2. Pr Protect client’s password against malicious server

Threat model

9

C3 server

myPassword123

Client

myPassword123

alice@email.com

********

website.com

alice@email.com passwordGuess1

Ideally, no information about password leaked Partial information speeds up online guessing attacks

alice@email.com passwordGuessQ

slide-10
SLIDE 10

Private set membership

10

C3 server Client myPassword123

Passwords … dog456 abc123 1password23 …

Private set membership? Doesn’t scale to sets containing hundreds of millions of elements Need to preserve privacy for both client credentials and server database

slide-11
SLIDE 11

Efficiency through bucketization

11

C3 server Client

myPassword123

Passwords … dog456 myPassword123 …

Combine bucketization with some private set membership protocol

slide-12
SLIDE 12

Efficiency through bucketization

12

C3 server

Have I Been Pwned and Google Password Checkup use a hash prefix as a bucket identifier Ke Key y secu curity y question: How much does knowing the bucket queried help an adversary guess a client’s password?

Client

myPassword123 Combine bucketization with some private set membership protocol

slide-13
SLIDE 13
  • Existing C3 service that checks if your username OR

password exists in a known data breach

Have I Been Pwned (HIBP)

13

slide-14
SLIDE 14

Have I Been Pwned (HIBP)

14

password123

Hash of password123 = 15a56bd4dd…

15a56

15a56

Have I Been Pwned

Contains all password hashes with the same prefix 20-bit hash prefix

slide-15
SLIDE 15

Security of HIBP

15a56

Bu Bucket 15a56 password123 enrique24 lilone55 pourmixl …

More popular Less popular

With no info: 431st guess With hash prefix: 1st guess

An attacker with access to the bucket and Q guesses has about the same success rate as an attacker with Q*B guesses! (B is the total number of buckets)

For HIBP, B = 220 ≈ 1 million

15

Attacker’s guess order of passwords

Compromise account with Q=10 guesses

slide-16
SLIDE 16

Issue with HIBP

16

Password Probability Easy to guess the password if you know the bucket

Buckets

Colors in buckets correspond to probabilities of passwords given the bucket

slide-17
SLIDE 17

Frequency-smoothing bucketization (FSB)

17

Password Probability Go Goal: : Given a bucket, the probability of each password in the bucket is the same

Buckets

We propose FSB as a more secure bucketization algorithm

slide-18
SLIDE 18

FSB implementation details (Q = 1)

18

Password Probability

B: # buckets

Buckets: 0 B 𝑗

Start bucket: H(◼) Proportional to probability of password Range for password ◼ [ H(◼) , H(◼) + f(Pr(◼)) ] To check a password with the server: Client computes range, picks a bucket randomly

slide-19
SLIDE 19
  • Parameter Q reflects expected online guessing budget
  • Include the top Q passwords in every bucket, and

distribute the rest proportionally to probability

FSB: what about Q > 1?

19

slide-20
SLIDE 20

FSB: guessing budget parameter

20

Password Probability

Q = 1

B Buckets: 0 𝑗 Bucket 𝑗:

slide-21
SLIDE 21

FSB: guessing budget parameter

21

B Buckets: 0

Q = 2

Password Probability

𝑗 Bucket 𝑗:

slide-22
SLIDE 22
  • Theorem: If an attacker has ≤ Q guesses,

access to the FSB bucket will give no no ad advan antag age over baseline guessing

  • Bounds for > Q guesses shown in our paper
  • Higher Q → smaller security loss
  • But also larger bucket sizes

Security of FSB

22

slide-23
SLIDE 23
  • How easily can an attacker guess passwords given the bucket

identifiers?

  • Breach dataset of 1.4 billion username-password pairs
  • Split into test set and leaked password set
  • Sample passwords randomly from test set
  • Record the number of guesses needed to recover the correct

password

Empirical security evaluation

23

github.com/lucy7li/compromised-credential-checking

slide-24
SLIDE 24

10 20 30 40 50 60 70 80 1 10 100 1000

Attacker success rate (%)

Number of queries given to the attacker Baseline Hash Prefix (20 bits) Frequency-smoothing (Q=100)

Results

24

HIBP FSB (Q=100)

Baseline

slide-25
SLIDE 25
  • Checks if a password is in breach data
  • HIBP leaks information about passwords that

speeds up remote guessing attacks

  • Frequency-smoothing bucketization leaks less
  • However, password-only checks may have false

positives

Recap of password-only C3 setting

25

slide-26
SLIDE 26
  • Check for an exact username-password pair match with a C3

server

  • Google Password Checkup (GPC) implemented a protocol that

uses the prefix of H(user || pw) as the bucket identifier

  • Bucket contains all H(user || pw) with the same hash prefix
  • Runs into same security issues as HIBP, if

if username is is known

ID-password C3 protocols

26

slide-27
SLIDE 27

GPC empirical security

27

10 20 30 40 50 60 70 80 1 10 100 1000

Attacker success rate (%) Number of queries given to the attacker

Baseline Hash Prefix (20 bits) Hash Prefix (16 bits) Frequency-smoothing (q'=100)

HIBP FSB

Baseline

GPC

slide-28
SLIDE 28
  • We propose a modification of GPC that only uses the hash prefix
  • f the username as a bucket identifier (ID-based bucketization,

IDB)

  • Google independently proposed this change in their paper, as a

future modification to their initial design [Thomas et al. 2019]

  • We show that knowing the IDB bucket identifier gives an attacker

no advantage in guessing a user’s password (over baseline guessing)!

ID-based bucketization (IDB)

28

slide-29
SLIDE 29

Performance

29

Setting Protocol Bandwidth (KB) Total time (ms) Password-

  • nly

HIBP 32 220 FSB 558 527 ID-password GPC 1,066 489 IDB 1,066 517

To Total tal ti time includes client-server communication and client- and server-side computations github.com/lucy7li/compromised-credential-checking

slide-30
SLIDE 30
  • Existing deployed C3 protocols leak a lot of

information about a user’s password to the C3 server

  • To leak less information, we recommend using:
  • Password-only: Frequency-smoothing bucketization
  • Username-password: ID-based bucketization
  • Questions?

Conclusion

30

github.com/lucy7li/compromised-credential-checking