Phoenix: Rebirth of a Cryptographic Password-Hardening Service

Russell W.F. Lai 1,2

Christoph Egger 1

Dominique Schroder 1

Sherman S.M. Chow 2

1Friedrich-Alexander-UniversitatErlangen-Nurnberg

2Chinese University of Hong Kong

August 17, 2017

Phoenix: Rebirth of a Cryptographic Password-Hardening Service Russell W. F. Lai

Scheme Design

2 of 26

Password Authentication - before 1976

UserUsername AlicePassword 123456

DatabaseUsername AlicePassword pw

Salt aqZcSP

I am “Alice”.

My password is “123456”.

Validation Algorithm

pw?= 123456

3 of 26

Salt aqZcSP

I am “Alice”.

pw?= 123456

3 of 26

Salt aqZcSP

I am “Alice”.

pw?= 123456

3 of 26

Password Authentication - after 1976

DatabaseUsername Alice

Hash hSalt aqZcSP

I am “Alice”.

h?= H(123456, aqZcSP)

3 of 26

Problem I - Weak Passwords

Worst Passwords of 2016 by TeamsID

• 4% of users use “123456” as password• 25% of users use the top 25 worst passwords• Users are stubborn◦ Choose stronger passwords◦ Use crypto

4 of 26

Problem II - Stolen Passwords

Data breaches in 2004–2017 (Wikipedia)

Cost of Data Breach(IBM - 2017 Study)

• Average Cost per DataBreach: $3.62 million

• Average Cost per StolenRecord $141

Service providers haveincentives to change!

5 of 26

Password Hardening Services (Facebook, Pythia)

“Alice”

“123456”

OK!Database

Username AliceCiphertext c

Verification Algorithm Protocol

〈C(skC, c,Alice, 123456),S(skS ,Alice)〉valCrypto Server (Server)

6 of 26

“Alice”

“123456”

OK!Database (Client)Username AliceCiphertext c

〈C(skC , c,Alice, 123456),S(skS ,Alice)〉valCrypto Server (Server)

6 of 26

“Alice”

“123456”

Key Features

• Seamless to end user (Alice)

• Obliviousness: (Malicious) server does not learn password

• Hiding: (Compromised) client cannot verify password by itself– eliminate offline attacks

• Rate-Limiting (per Username): (Compromised) client cannotsubmit too many requests

– mitigate online attacks

6 of 26

“Alice”

“123456”

Messages from client are independent of passwords!

Key Features

6 of 26

“Alice”

“123456”

Key Features

6 of 26

“Alice”

“123456”

Database (Client)Username AliceCiphertext c

Key Features

6 of 26

“Alice”

“123456”

〈C(skC, c,Alice, 000000),S(skS ,Alice)〉valCrypto Server (Server)

Key Features

– mitigate online attacks6 of 26

“Alice”

“123456”

〈C(skC , c,Alice, qwerty),S(skS ,Alice)〉valCrypto Server (Server)

Key Features

“Alice”

“123456”

〈C(skC , c,Alice, asdfgh),S(skS ,Alice)〉valCrypto Server (Server)

Key Features

“Alice”

“123456”

Too many requests!Crypto Server (Server)

Key Features

“Alice”

“123456”

Key Features

• Key-Rotation◦ Update both keys if either party is compromised◦ Bring the entire system to a fresh state◦ Update ciphertexts without knowing passwords (seamless to end user)

6 of 26

“Alice”

“123456”

Key Features

• Key-Rotation◦ Update both keys if either party is compromised◦ Bring the entire system to a fresh state◦ Update ciphertexts without knowing passwords (seamless to end user)

6 of 26

The Crypto Server

Crypto Server

• Key generation independent of client◦ Can be set up by any third party company / organization◦ One server can serve multiple clients

• Only stores:◦ One secret key per client◦ One counter per end user for rate-limiting

(deleted after the current time interval)

• Can be split into multiple servers (future work)

7 of 26

The Crypto Server

Crypto Server

7 of 26

The Crypto Server

Crypto Server

7 of 26

False Friends (Similar but different notions)

Common Feature

• To distribute the task of verifying passwords to multiple servers

Distributed Password Verification(CCS’15) Camenisch, Lehmann, and Neven

• Joint key generation between client and server

• Rate-limiting at client only

Password-Authenticated Key Exchange (PAKE) /Password-Protected Secret Sharing (PPSS)

• Crypto servers need to store a secret share per end user

• No / inefficient key rotations

8 of 26

Common Feature

• No / inefficient key rotations

8 of 26

Common Feature

• No / inefficient key rotations8 of 26

Literature on Password Hardening (PH)

Partially-Oblivious Pseudorandom Functions (PO-PRF)(USENIX’15) Everspaugh, Chatterjee, Scott, Juels, and Ristenpart

• Formalized PO-PRF

• Construction (Pythia) based on pairing

Partially-Oblivious Commitments (PO-Com)(CCS’16) Schneider, Fleischhacker, Schroder, and Backes

• Formalized PO-Com◦ Security definitions too weak for PH (not covering online attacks)

• Construction without pairing◦ 2× faster than Pythia when used for PH

9 of 26

Literature on Password Hardening (PH)

Partially-Oblivious Pseudorandom Functions (PO-PRF)(USENIX’15) Everspaugh, Chatterjee, Scott, Juels, and Ristenpart

• Formalized PO-PRF

• Construction (Pythia) based on pairing

Partially-Oblivious Commitments (PO-Com)(CCS’16) Schneider, Fleischhacker, Schroder, and Backes

• Formalized PO-Com◦ Security definitions too weak for PH (not covering online attacks)

• Construction without pairing◦ 2× faster than Pythia when used for PH

9 of 26

This Work

• Finally, formalized PH◦ Revisit and strengthen model of Schneider et al.

• Formalized key-rotation

• Devastating online attacks against scheme of Schneider et al.◦ Attack 1: Enable offline-dictionary attack after one validation request◦ Attack 2: Extract password after one validation request◦ The attacks defeat the purpose of external crypto server◦ The attacks are outside of their security model

• Extremely simple construction (still without pairing)◦ Simple enough for real-world use – easy to understand and implement◦ Proven secure under strengthened security model◦ 1.5× faster than scheme of Schneider et al.◦ 3× faster than Pythia

10 of 26

This Work

10 of 26

This Work

10 of 26

This Work

10 of 26

From Salted Hash to Phoenix (Intuitive Description)

Database (Client)Username un

Hash H(un, pw, nC)Client Nonce nC

Server Nonce

Enrollment Protocol

Username un

PRF Value

Server Nonce nS

Crypto Server (Server)

11 of 26

Database (Client)Username unPRF Value PRFsk(un, pw, nC)

Client Nonce nC

Server Nonce

Enrollment Protocol

Username un

PRF Value

Server Nonce nS

11 of 26

Product PRF ValuePRFskS (un, nS)·

PRFskC (un, pw, nC)Client Nonce nCServer Nonce nS

Enrollment Protocol

Username un

PRF Value PRFskS (un, nS)

Server Nonce nS

11 of 26

Ciphertext Enc

(pkS ,

PRFskS (un, nS)·PRFskC (un, pw, nC)

)Client Nonce nCServer Nonce nS

Enrollment Protocol

Username un

PRF Value PRFskS (un, nS)

Server Nonce nS

11 of 26

Ciphertext Enc

(pkS ,

PRFskS (un, nS)·PRFskC (un, pw, nC)

)Client Nonce nCServer Nonce nS

Enrollment Protocol

Username un

PRF Value HS(un, nS)kS

Server Nonce nS

Homomorphic Encryption

Enc(pk,m ·m′) ≈Enc(pk,m) · Enc(pk,m′)

Key-Homomorphic PRF

PRFsk·sk′(m) =PRFsk(m) · PRFsk′(m)

11 of 26

(g r , hr · HS(un, nS)kS · HC(un, pw, nC)

kC )Client Nonce nCServer Nonce nS

Enrollment Protocol

Username un

PRF Value

Server Nonce nS

e.g., ElGamal (and variants)

sk = s, pk = h = g s

c = (g r , hr ·m)

(g r+r ′ , hr+r ′ ·m ·m′) =(g r , hr ·m) · (g r ′ , hr

′ ·m′)

e.g., Naor-Pinkas-Reingold

sk = ky = H(m)k

H(m)k+k ′= H(m)k · H(m)k

11 of 26

Phoenix Validation (Intuitive Description)

Database (Client)Username unCiphertext (g r , hr · HS(un, nS)kS · HC(un, pw, nC)kC )

Client Nonce nCServer Nonce nS

Validation Protocol

hr · HS(un, nS)kS =hr · HS(un, nS)kS · HC(un, pw, nC)kC

HC(un, pw, nC)kC

(g r , hr · HS(un, nS)kS ), un, nS

Is un requested too many times?

Is the ciphertext valid?

Prove(The ciphertext is valid!)

12 of 26

Validation Protocol

HC(un, pw, nC)kC

12 of 26

Validation Protocol

HC(un, pw, nC)kC

12 of 26

Validation Protocol

HC(un, pw, nC)kC

12 of 26

Validation Protocol

HC(un, pw, nC)kC

12 of 26

Why it works?

• Obliviousness:◦ Nothing about the password is sent to the server

• Hiding:◦ PRF values of the passwords are encrypted to the server◦ Client cannot decrypt by itself◦ Validity check binds (un, nS) with HS(un, nS)kS in c◦ Online attacks require guessing pw to remove HC(pw, nC)kC from c

13 of 26

Why it works?

• Obliviousness:◦ Nothing about the password is sent to the server

• Hiding:◦ PRF values of the passwords are encrypted to the server◦ Client cannot decrypt by itself◦ Validity check binds (un, nS) with HS(un, nS)kS in c◦ Online attacks require guessing pw to remove HC(pw, nC)kC from c

13 of 26

Phoenix Key-Rotation (Intuitive Description)

Database (Client) Crypto Server (Server)

g s·r · HS(un, nS)kS · HC(un, pw, nC)kC

↓ˆαgα·s·r · HS(un, nS)α·kS · HC(un, pw, nC)α·kC

↓ ·(g r )β · HS(un, nS)γ

g (α·s+β)·r · HS(un, nS)α·kS+γ · HC(un, pw, nC)α·kC

g s′·r · HS(un, nS)k′S · HC(un, pw, nC)k

14 of 26

Phoenix Key-Rotation (Intuitive Description)

Database (Client) Crypto Server (Server)

g s·r · HS(un, nS)kS · HC(un, pw, nC)kC

↓ˆαgα·s·r · HS(un, nS)α·kS · HC(un, pw, nC)α·kC

↓ ·(g r )β · HS(un, nS)γ

g (α·s+β)·r · HS(un, nS)α·kS+γ · HC(un, pw, nC)α·kC

g s′·r · HS(un, nS)k′S · HC(un, pw, nC)k

14 of 26

Phoenix: Rebirth of a Cryptographic Password-Hardening Service Christoph Egger

Evaluation and Deployment

15 of 26

Evaluation

In Comparison

Current password hashing recommendations suggest up to one secondsingle-core computing time

ContextWe have all three (python based) implementations running onAmazon AWS single-core instances

Questions

• How long does the user have to wait for password verification

• Do we need many servers to support Password-Hardening

• What are the practical implications

16 of 26

Evaluation

How long must the end user wait for to log in?

≈ 8 ms! (+ round trip time)

Frankfurt IrelandHTTP HTTPS HTTPS HTTP HTTPS HTTPS

keep-alive keep-alive

RTT (64 bytes) 1.2 23

Pythia enroll/validate 17.93 25.28 16.01 62.03 113.79 38.56

Schneider et al. enroll 9.80 22.86 8.14 53.72 111.40 30.89Schneider et al. validate 12.30 25.65 10.73 56.32 115.32 33.49

Phoenix enroll 5.43 17.93 3.89 50.30 107.25 26.52Phoenix validate 9.74 22.78 8.06 53.92 113.02 30.73

Latency in millisecond (ms)

17 of 26

Evaluation

How long must the end user wait for to log in?

≈ 8 ms! (+ round trip time)

Frankfurt IrelandHTTP HTTPS HTTPS HTTP HTTPS HTTPS

keep-alive keep-alive

RTT (64 bytes) 1.2 23

Pythia enroll/validate 17.93 25.28 16.01 62.03 113.79 38.56

Schneider et al. enroll 9.80 22.86 8.14 53.72 111.40 30.89Schneider et al. validate 12.30 25.65 10.73 56.32 115.32 33.49

Phoenix enroll 5.43 17.93 3.89 50.30 107.25 26.52Phoenix validate 9.74 22.78 8.06 53.92 113.02 30.73

Latency in millisecond (ms)

17 of 26

Evaluation

How many requests can the server entertain in one second?

Over 370!

HTTPS HTTPSkeep-alive

parameter 2, 607.16 807.50

Pythia enroll/validate 128.50 125.75

Schneider et al. enroll 380.37 278.51Schneider et al. validate 221.75 183.92

Phoenix enroll 1, 557.81 697.66Phoenix validate 371.34 275.42

Requests per second

18 of 26

Evaluation

How many requests can the server entertain in one second?

Over 370!

HTTPS HTTPSkeep-alive

parameter 2, 607.16 807.50

Pythia enroll/validate 128.50 125.75

Schneider et al. enroll 380.37 278.51Schneider et al. validate 221.75 183.92

Phoenix enroll 1, 557.81 697.66Phoenix validate 371.34 275.42

Requests per second

18 of 26

Practical Deployment

Hybrid Scheme

Can we make use of memory-hard functions like Argon2 or scrypt?

• Use a memory-hard function instead of a traditional hash functionfor the PRF

• Even if the attacker has compromised both Client and Server,she has to use the memory-hard function for dictionary attacks

Naor-Pinkas-Reingold

sk = kPRF value

19 of 26

Hybrid Scheme

sk = kPRF value H(x)k

19 of 26

Hybrid Scheme

sk = kPRF value Sha256(x)k

19 of 26

Hybrid Scheme

sk = kPRF value Argon2(x)k

19 of 26

Availability

What happens when the Crypto Server is unavailable?

• Server only holds key-pair per Client and Rate-Limiting information

• Several Crypto Servers can host the key-pair for availability butkeys are then located on several machines

20 of 26

Availability

20 of 26

Availability

20 of 26

Availability

20 of 26

DDoS and Rate-Limiting

There are two scenarios where Rate-Limiting might be triggered:

Client has been compromised

• It is acceptable when users fail to log in

Alice123456

21 of 26

Client has been compromised

• It is acceptable when users fail to log in

Alice123456

21 of 26

External Attacker

• Honest users should only be slightly inconvenienced

• Crypto Server has little information to distinguish users

• Client is honest and can therefore help

Alice123456

21 of 26

External Attacker

• Honest users should only be slightly inconvenienced

• Crypto Server has little information to distinguish users

• Client is honest and can therefore help

Alice123456

Alicepassword

21 of 26

Rate-Limiting external clients

• Warn the Client about upcoming Rate-Limiting:once a soft limit is exceededthere is a limited number of additional tries availablethe client needs to make sure only the honest user gets to use these

• Client then takes extra measures, for example◦ Send an E-Mail / SMS / . . . with an one-time code to the user◦ Add Puzzles to the login screen

22 of 26

Alicepassword

23 of 26

Alice000000

23 of 26

Alicequerty

23 of 26

Aliceasdfgh

23 of 26

SMS:Token=SECRET

23 of 26

Alice098765

23 of 26

Missing Token

23 of 26

AlicepasswordSECRET

23 of 26

Upgrade Path

• Both, salted hash and Phoenix need a database field to store data

• Algorithm-ID often already stored alongside the salt and hash

• Upgrade users once they log in

Username Password Data

Alice 12:PeADRGbk:gaG4s[...]2BwM= . . .Bob 12:q79JVDSo:IIRBz[...]/9L4= . . .Carol 5:3V+ToDHL:FCozKw/gxP/9YZ+Pdr7pcg== . . .

24 of 26

Upgrade Path

• Both, salted hash and Phoenix need a database field to store data

• Algorithm-ID often already stored alongside the salt and hash

• Upgrade users once they log in

Username Password Data

Alice 12:PeADRGbk:gaG4s[...]2BwM= . . .Bob 13:MxTfsL[...]phh+8i3DU== . . .Carol 5:3V+ToDHL:FCozKw/gxP/9YZ+Pdr7pcg== . . .

24 of 26

Concluding Remark

Summary

• Strengthened model of password-hardening

• Formal treatment to key-rotation

• Devastating attack to an existing scheme

• Phoenix: The most efficient scheme to date

On Going Projects

• Extended functionality – Derive key upon successful validation

• Anonymize end user while retaining rate-limiting

• Deployment by start-up company

25 of 26

Concluding Remark

Summary

• Strengthened model of password-hardening

• Formal treatment to key-rotation

• Devastating attack to an existing scheme

• Phoenix: The most efficient scheme to date

On Going Projects

• Extended functionality – Derive key upon successful validation

• Anonymize end user while retaining rate-limiting

• Deployment by start-up company

25 of 26

Russell W. F. LaiFAU Nuremberg ←Chinese U. Hong Kong

Christoph EggerFAU Nuremberg

Dominique SchroderFAU Nuremberg

Sherman S. M. ChowChinese U. Hong Kong

26 of 26

Phoenix: Rebirth of a Cryptographic Password-Hardening Service · Problem I - Weak Passwords Worst...

Transcript of Phoenix: Rebirth of a Cryptographic Password-Hardening Service · Problem I - Weak Passwords Worst...

Phoenix: Rebirth of a Cryptographic Password-Hardening Service · Problem I - Weak Passwords Worst...

Documents

Transcript of Phoenix: Rebirth of a Cryptographic Password-Hardening Service · Problem I - Weak Passwords Worst...

A more user-friendly password method would allow users to generate passwords that are more resistant to cracking than present standards

Password Fallback Authentication › Resource resorted to when users forget their passwords Existing Tools › CAPTCHA › Pre-defined questions › User-defined.

Multiple Password Interference in Text Passwords and Click-Based Graphical Passwordspaulv/papers/ccs09.pdf · 2009. 8. 27. · Multiple Password Interference in Text Passwords and

Protect your passwords with Password Manager - myroyalmail Quic… · Protect your passwords with Password Manager What is it? Password Manager is an online service that enables you

Weøsite Passwords O 000 Website: Username: Password: Email ... · Weøsite Passwords O 000 Website: Username: Password: Email: Other: Website: Username: Password: Email: Other: Website:

Chapter 7 Passwords · Chapter 7 Passwords In This Chapter Identifying password vulnerabilities Examining password-hacking tools and techniques Hacking operating-system passwords

Protecting Windows Passwords and Preventing Windows Computer / Password Attacks

Password Based Authentication Scheme: Safety and ...2 Password based Authentication Textual Passwords Graphical Passwords Attacks on Password Based Scheme 3 Existing Techniques DAS

Password Tips · Suggested Password Strategy Create strong, memorable passphrases for your key passwords. 1. Password manager program’s master password. 2. Computer login password.

Password Cracking / Brute-Force Tools - Security Science · computer network, users’ passwords have to be strong enough so that Dwayne ... Password Cracking / Brute-Force Tools

From Very Weak to Very Strong Analyzing Password-Strength …€¦ · 06/09/2017 · meters on many websites to encourage users to choose strong passwords. Password meters are generally

Passwords and User Behavior - JCOMPUTERS · Password memorability and security[12] Users tend to decrease their password security for the sake of password memorability. Difficult

Password managers · Passwords just won’t die We don’t really have a better way yet Users understand passwords Most users can’t manage one-time keys Most users don’t understand

Password Cracking 2020 Didier Guillevic · Didier Guillevic Password Cracking - 2020 Summary - TL;DR 3 How passwords are stored How passwords are cracked 1. Brute force (short password,

Conference Overview. PASSWORDS You can set your password policy to enforce users to change their passwords periodically.

Graphical Passwords and Practical Password Management · Graphical Passwords and Practical Password Management By Elizabeth Ann Stobert Athesissubmittedto theFacultyofGraduateandPostdoctoralAﬀairs

Passwords Aim: To create a strong and safe password.

Passwords - SANS · Password recommendations •Make your password a sentence •Unique account, unique password •Write down your passwords •Use 2-factor authentication

Managing Passwords for Mobile Users

Genaral Information - Efficient Password Manager · Password Manager Passwords Software Registrat10h Codes Email Accounts Account My Pass wards All passwords Cards Website work öther