Phoenix: Rebirth of a Cryptographic Password-Hardening Service

Transcription

1 Phoenix: Rebirth of a Cryptographic Password-Hardening Service Russell W.F. Lai 1,2 Christoph Egger 1 Dominique Schro der 1 Sherman S.M. Chow 2 1 Friedrich-Alexander-Universita t Erlangen-Nu rnberg University of Hong Kong 2 Chinese August 17, 2017

2 Scheme Design 2 of 26

3 Password Authentication - before 1976 User Username Alice Password Database Username Alice Password pw I am Alice. My password is of 26

4 Password Authentication - before 1976 User Username Alice Password Database Username Alice Password pw I am Alice. My password is Validation Algorithm pw? = of 26

5 Password Authentication - before 1976 User Username Alice Password Database Username Alice Password pw I am Alice. My password is Validation Algorithm pw? = OK! 3 of 26

6 Password Authentication - after 1976 User Username Alice Password I am Alice. My password is Database Username Alice Hash h Salt aqzcsp 3 of 26 OK! Validation Algorithm h? = H(123456, aqzcsp)

7 Problem I - Weak Passwords Worst Passwords of 2016 by TeamsID 4% of users use as password 25% of users use the top 25 worst passwords Users are stubborn Choose stronger passwords Use crypto 4 of 26

8 Problem II - Stolen Passwords Data breaches in (Wikipedia) 5 of 26

9 Problem II - Stolen Passwords Cost of Data Breach (IBM Study) Average Cost per Data Breach: $3.62 million Average Cost per Stolen Record $141 Data breaches in (Wikipedia) 5 of 26

10 Problem II - Stolen Passwords Cost of Data Breach (IBM Study) Average Cost per Data Breach: $3.62 million Average Cost per Stolen Record $141 Service providers have incentives to change! Data breaches in (Wikipedia) 5 of 26

11 Password Hardening Services (Facebook, Pythia) Alice OK! Database Username Alice Ciphertext c 6 of 26

12 Password Hardening Services (Facebook, Pythia) Alice Verification Algorithm Protocol Alice OK! Database (Client) Username Alice Ciphertext c C(skC, c, Alice, ), S(skS, Alice) val Crypto Server (Server) 6 of 26

13 Password Hardening Services (Facebook, Pythia) Alice Verification Algorithm Protocol Alice OK! Database (Client) Username Alice Ciphertext c C(skC, c, Alice, ), S(skS, Alice) val Crypto Server (Server) Key Features Seamless to end user (Alice) 6 of 26

14 Password Hardening Services (Facebook, Pythia) Alice Verification Algorithm Protocol Alice OK! Database (Client) Username Alice Ciphertext c C(skC, c, Alice, ), S(skS, Alice) val Crypto Server (Server) Key Features Messages from client are independent of passwords! Seamless to end user (Alice) Obliviousness: (Malicious) server does not learn password 6 of 26

15 Password Hardening Services (Facebook, Pythia) Alice Verification Algorithm Protocol Alice OK! Database (Client) Username Alice Ciphertext c C(skC, c, Alice, ), S(skS, Alice) val Crypto Server (Server) 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 6 of 26

16 Password Hardening Services (Facebook, Pythia)?? Alice Verification Algorithm Protocol Alice OK! Database (Client) Username Alice Ciphertext c C(skC, c, Alice, ), S(skS, Alice) val Crypto Server (Server) 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 6 of 26

17 Password Hardening Services (Facebook, Pythia) Alice Verification Algorithm Protocol Alice OK! Database (Client) Username Alice Ciphertext c C(skC, c, Alice, ), S(skS, Alice) val Crypto Server (Server) 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 cannot submit too many requests mitigate online attacks 6 of 26

18 Password Hardening Services (Facebook, Pythia) Alice Verification Algorithm Protocol Alice OK! Database (Client) Username Alice Ciphertext c C(skC, c, Alice, qwerty), S(skS, Alice) val Crypto Server (Server) 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 cannot submit too many requests mitigate online attacks 6 of 26

19 Password Hardening Services (Facebook, Pythia) Alice Verification Algorithm Protocol Alice OK! Database (Client) Username Alice Ciphertext c C(skC, c, Alice, asdfgh), S(skS, Alice) val Crypto Server (Server) 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 cannot submit too many requests mitigate online attacks 6 of 26

20 Password Hardening Services (Facebook, Pythia) Alice Verification Algorithm Protocol Alice OK! Database (Client) Username Alice Ciphertext c Too many requests! Crypto Server (Server) 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 cannot submit too many requests mitigate online attacks 6 of 26

21 Password Hardening Services (Facebook, Pythia) Alice Verification Algorithm Protocol Alice OK! Database (Client) Username Alice Ciphertext c C(skC, c, Alice, ), S(skS, Alice) val Crypto Server (Server) 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

22 Password Hardening Services (Facebook, Pythia) Alice Verification Algorithm Protocol Alice OK! Database (Client) Username Alice Ciphertext c C(skC, c, Alice, ), S(skS, Alice) val Crypto Server (Server) 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

23 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 7 of 26

24 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) 7 of 26

25 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

26 False Friends (Similar but different notions) Common Feature To distribute the task of verifying passwords to multiple servers 8 of 26

27 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 8 of 26

28 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

29 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 9 of 26

30 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, Schröder, 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

31 This Work Finally, formalized PH Revisit and strengthen model of Schneider et al. 10 of 26

32 This Work Finally, formalized PH Revisit and strengthen model of Schneider et al. Formalized key-rotation 10 of 26

33 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 10 of 26

34 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

35 From Salted Hash to Phoenix (Intuitive Description) Database (Client) Username un Hash H(un, pw, n C) Client Nonce n C 11 of 26

36 From Salted Hash to Phoenix (Intuitive Description) Database (Client) Username un PRF Value PRF sk(un, pw, n C) Client Nonce n C 11 of 26

37 From Salted Hash to Phoenix (Intuitive Description) Database (Client) Username un PRF Product PRF Value sks (un, n S) PRF skc (un, pw, n C) Client Nonce n C Server Nonce n S Enrollment Protocol Username un PRF Value PRF sks (un, n S) Server Nonce n S Crypto Server (Server) 11 of 26

38 From Salted Hash to Phoenix (Intuitive Description) Database (Client) Username un ( ) PRFsk Ciphertext Enc pk S, S (un, ns) PRFsk C (un, pw, nc) Client Nonce nc Server Nonce ns Enrollment Protocol Username un PRF Value PRFsk S (un, ns) Server Nonce ns Crypto Server (Server) 11 of 26

39 From Salted Hash to Phoenix (Intuitive Description) Database (Client) Username un ( ) PRFsk Ciphertext Enc pk S, S (un, ns) PRFsk C (un, pw, nc) Client Nonce nc Server Nonce ns Homomorphic Encryption Enc(pk, m m ) Enc(pk, m) Enc(pk, m ) Enrollment Protocol Username un PRF Value HS(un, ns) k S Server Nonce ns Crypto Server (Server) Key-Homomorphic PRF PRF sk sk (m) = PRF sk (m) PRF sk (m) 11 of 26

40 From Salted Hash to Phoenix (Intuitive Description) Database (Client) Username un (g r, h r HS(un, ns) ks HC(un, pw, nc) k C ) Client Nonce nc Server Nonce ns e.g., ElGamal (and variants) sk = s, pk = h = g s c = (g r, h r m) Enrollment Protocol Username un PRF Value Server Nonce ns Crypto Server (Server) e.g., Naor-Pinkas-Reingold sk = k y = H(m) k (g r+r, h r+r m m ) = (g r, h r m) (g r, h r m ) H(m) k+k = H(m) k H(m) k 11 of 26

41 Phoenix Validation (Intuitive Description) Database (Client) Username un Ciphertext (g r, h r H S(un, n S) ks H C(un, pw, n C) kc ) Client Nonce n C Server Nonce n S Crypto Server (Server) 12 of 26

42 Phoenix Validation (Intuitive Description) Database (Client) Username un Ciphertext (g r, h r H S(un, n S) ks H C(un, pw, n C) kc ) Client Nonce n C Server Nonce n S Crypto Server (Server) Validation Protocol h r H S(un, n S) ks = hr H S(un, n S) ks H C(un, pw, n C) kc H C(un, pw, n C) kc 12 of 26

43 Phoenix Validation (Intuitive Description) Database (Client) Username un Ciphertext (g r, h r H S(un, n S) ks H C(un, pw, n C) kc ) Client Nonce n C Server Nonce n S Crypto Server (Server) Validation Protocol h r H S(un, n S) ks = hr H S(un, n S) ks H C(un, pw, n C) kc H C(un, pw, n C) kc (g r, h r HS(un, ns) ks ), un, ns 12 of 26

44 Phoenix Validation (Intuitive Description) Database (Client) Username un Ciphertext (g r, h r H S(un, n S) ks H C(un, pw, n C) kc ) Client Nonce n C Server Nonce n S Crypto Server (Server) Validation Protocol h r H S(un, n S) ks = hr H S(un, n S) ks H C(un, pw, n C) kc H C(un, pw, n C) kc (g r, h r HS(un, ns) ks ), un, ns Is un requested too many times? Is the ciphertext valid? 12 of 26

45 Phoenix Validation (Intuitive Description) Database (Client) Username un Ciphertext (g r, h r H S(un, n S) ks H C(un, pw, n C) kc ) Client Nonce n C Server Nonce n S Crypto Server (Server) Validation Protocol h r H S(un, n S) ks = hr H S(un, n S) ks H C(un, pw, n C) kc H C(un, pw, n C) kc (g r, h r HS(un, ns) ks ), un, ns Prove(The ciphertext is valid!) Is un requested too many times? Is the ciphertext valid? 12 of 26

46 Why it works? Obliviousness: Nothing about the password is sent to the server (g r, h r H S (un, n S ) k S ), un, n S 13 of 26

47 Why it works? Obliviousness: Nothing about the password is sent to the server (g r, h r H S (un, n S ) k S ), un, n S Hiding: PRF values of the passwords are encrypted to the server Client cannot decrypt by itself Validity check binds (un, n S ) with H S (un, n S ) k S in c Online attacks require guessing pw to remove H C (pw, n C ) k C from c 13 of 26

48 Phoenix Key-Rotation (Intuitive Description) Database (Client) Crypto Server (Server) g s r H S (un, n S ) ks H C (un, pw, n C ) k C 14 of 26

49 Phoenix Key-Rotation (Intuitive Description) Database (Client) Crypto Server (Server) g s r H S (un, n S ) ks H C (un, pw, n C ) k C ˆα g α s r H S (un, n S ) α ks H C (un, pw, n C ) α k C (g r ) β H S(un, n S) γ g (α s+β) r H S (un, n S ) α k S+γ H C (un, pw, n C ) α k C = g s r H S (un, n S ) k S HC (un, pw, n C ) k C 14 of 26

50 Christoph Egger Evaluation and Deployment 15 of 26

51 Christoph Egger Evaluation In Comparison Current password hashing recommendations suggest up to one second single-core computing time Context We have all three (python based) implementations running on Amazon 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

52 Christoph Egger Evaluation How long must the end user wait for to log in? 17 of 26

53 Christoph Egger Evaluation How long must the end user wait for to log in? 8 ms! (+ round trip time) Frankfurt Ireland HTTP HTTPS HTTPS HTTP HTTPS HTTPS keep-alive keep-alive RTT (64 bytes) Pythia enroll/validate Schneider et al. enroll Schneider et al. validate Phoenix enroll Phoenix validate Latency in millisecond (ms) 17 of 26

54 Christoph Egger Evaluation How many requests can the server entertain in one second? 18 of 26

55 Christoph Egger Evaluation How many requests can the server entertain in one second? Over 370! HTTPS HTTPS keep-alive parameter 2, Pythia enroll/validate Schneider et al. enroll Schneider et al. validate Phoenix enroll 1, Phoenix validate Requests per second 18 of 26

56 Christoph Egger Practical Deployment Hybrid Scheme Can we make use of memory-hard functions like Argon2 or scrypt? 19 of 26

57 Christoph Egger 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 function for 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 = k PRF value H(x) k 19 of 26

58 Christoph Egger 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 function for 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 = k PRF value Sha256(x) k 19 of 26

59 Christoph Egger 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 function for 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 = k PRF value Argon2(x) k 19 of 26

60 Christoph Egger Practical Deployment Availability What happens when the Crypto Server is unavailable? 20 of 26

61 Christoph Egger Practical Deployment 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 but keys are then located on several machines sk 20 of 26

62 Christoph Egger Practical Deployment 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 but keys are then located on several machines sk sk 20 of 26

63 Christoph Egger Practical Deployment 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 but keys are then located on several machines sk sk 20 of 26

64 Christoph Egger 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 Alice of 26

65 Christoph Egger 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 Alice of 26

66 Christoph Egger DDoS and Rate-Limiting There are two scenarios where Rate-Limiting might be triggered: External Attacker Honest users should only be slightly inconvenienced Crypto Server has little information to distinguish users Client is honest and can therefore help Alice of 26

67 Christoph Egger DDoS and Rate-Limiting There are two scenarios where Rate-Limiting might be triggered: External Attacker Honest users should only be slightly inconvenienced Crypto Server has little information to distinguish users Client is honest and can therefore help Alice Alice password 21 of 26

68 Christoph Egger Rate-Limiting external clients Warn the Client about upcoming Rate-Limiting: once a soft limit is exceeded there is a limited number of additional tries available the client needs to make sure only the honest user gets to use these Client then takes extra measures, for example Send an / SMS /... with an one-time code to the user Add Puzzles to the login screen 22 of 26

69 Christoph Egger Rate-Limiting external clients Alice password 23 of 26

70 Christoph Egger Rate-Limiting external clients Alice of 26

71 Christoph Egger Rate-Limiting external clients Alice querty 23 of 26

72 Christoph Egger Rate-Limiting external clients Alice asdfgh 23 of 26

73 Christoph Egger Rate-Limiting external clients Slow down! 23 of 26

74 Christoph Egger Rate-Limiting external clients SMS: Token=SECRET 23 of 26

75 Christoph Egger Rate-Limiting external clients Alice of 26

76 Christoph Egger Rate-Limiting external clients Missing Token 23 of 26

77 Christoph Egger Rate-Limiting external clients Alice password SECRET 23 of 26

78 Christoph Egger 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== of 26

79 Christoph Egger 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== of 26

80 Christoph Egger 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 25 of 26

81 Christoph Egger 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

82 Christoph Egger FAU Nuremberg Chinese U. Hong Kong Christoph Egger FAU Nuremberg Dominique Schröder FAU Nuremberg Sherman S. M. Chow Chinese U. Hong Kong 26 of 26