8: Password-Hashing Basics

Home , Crypt (C), Key stretching, Pepper (cryptography), Scrypt

I Passwords, Passphrases, “Personal Identiﬁcation Numbers” (PINs) are needed all the time

user name: Max passwort: ********

I Can be part of a “two-factor-authentication” (e.g., chipcard + PIN) I Adversaries trying to “guess” them:

I How probable is a pwd? I How to attack unknwon pwd by making X attempts to “guess” them I Which passwords are the X most probable ones? I How to choose pwd to thwart such attacks? I . . . while still being able to remember pwd?

Our goal: Make the usage of passwords as secure as possible.

–226– Stefan Lucks Hash Fun. & PW (S 2014) 8: Passw.-Hash Preliminaries . . . speaking words of wisdom, let it be, let it be, . . . (The Beatles)

I QUESTION: Which of the following passwords is OK? “53cur3 pa55w0rd”, “ci90n38!P0??3ah9vhv” or “123456”?

user name: Max passwort: ********

I ANSWER: None! (Not after being shown on my slides . . . )

I Passwords must be unpredictable ...

I BUT this is actually a property of password-generation and password-handling (random choices, not published on slides, . . . )

I information-theory: a “password-source” must have high entropy! k−1 I very informally: k-bit of entropy ≥ 2 “guesses” for the attacker

–227– Stefan Lucks Hash Fun. & PW (S 2014) 8: Passw.-Hash Wisdom # 1: Choose “high-entropy” passwords! . . . this is harder than it looks

–228– Stefan Lucks Hash Fun. & PW (S 2014) 8: Passw.-Hash Wisdom # 2: Do not allow Ofﬂine Attacks! . . . whenever you can avoid them

user name: Max passwort: ********

Online: Ofﬂine:

I access to server I function F

I adversary sends pwd-”guess” I adversary can compute F

I server accepts or rejects without the server’s aid pwd-”guess” I F(pwd) = 1 ⇔ pwd accepted X: as large as the server allows X: as large as the adversary can and can handle afford

–229– Stefan Lucks Hash Fun. & PW (S 2014) 8: Passw.-Hash Wisdom #3: Passwords in the Clear are bad! . . . worse than leaving the key to your ﬂat under the door-mat

name pwd Anakin skywalker Dagobert moneymoneymoney Donald enwo34qindk!d Luke sykwalker Tick mysecretpassword Trick mysecretpassword Track mysecretpassword

–230– Stefan Lucks Hash Fun. & PW (S 2014) 8: Passw.-Hash Wisdom # 4: Hashing Passwords helps . . . but is not good enough

name H(pwd) Anakin viqwbnqwtomwm Dagobert wer4mnrt4rnrm Donald r034jionksioe Luke viqwbnqwtomwm Tick sdjklasdle9nr Trick sdjklasdle9nr Track sdjklasdle9nr

best attack:

I assume “dictionary” with N “common” passwords

I compute another dictionary with N hashed passwords

I attacking each account in time O(1), if password is “common”

–231– Stefan Lucks Hash Fun. & PW (S 2014) 8: Passw.-Hash Wisdom # 5: Salt and Hash Passwords

name salt H(salt, pwd) Anakin 34892 4unuiio8nuue7 Dagobert 29495 ksni9m8k89kiu Donald 09858 cdk5jkambydyu Luke 45888 xumun6muzyqjo Tick 19495 cnjk9mk3msdfk Track 27849 dekcexcidklc7 Trick 90479 yei7kmdkx2dcx

best attack:

I assume “dictionary” with N “common” passwords

I attacking each account in time O(N), if password is “common” (if the salt never repeats)

–232– Stefan Lucks Hash Fun. & PW (S 2014) 8: Passw.-Hash 8.1: Key Stretching Wisdom # 6: Perform “Key Stretching”

I stretching by k bit k I attacks slow down 2 times I “virtual” entropy goes from β to β + k k I unfortunately, the defenders’ operations may also slow down by 2 times I so the idea is to

I choose k as large as possible I without annoying the defender

–233– Stefan Lucks Hash Fun. & PW (S 2014) 8: Passw.-Hash 8.1: Key Stretching Generate Password Hashes with Stretching

iteration: stretch by log (N) bit 2 pepper: stretch by p bit input: pwd, salt, N input: pwd, salt, p X ← H(salt, pwd) choose random R < 2p for I ← 1 to N do X ← H(salt, R, pwd) X ← H(salt, X) return X end for return X

–234– Stefan Lucks Hash Fun. & PW (S 2014) 8: Passw.-Hash 8.1: Key Stretching Verify Password Hashes verify iteration verify pepper input: pwd, salt, N, X 0 input: pwd, salt, p, X 0 X ← H(salt, pwd) choose random R0 < 2p for I ← 1 to N do for I ← 0 to 2p − 1 do X ← H(salt, X) R00 ← (R0 + I) mod 2p end for X 0 ← H(salt, R00, X) accept if X = X 0 else reject accept if X = X 0 end for reject Advantages and disadvantages: +iteration generation and veriﬁcation are the same +pepper fast generation +pepper parallelizable (why is this an advantage for the defender, and not a disadvantage?) -pepper R must be random – and even secret (why?)

–235– Stefan Lucks Hash Fun. & PW (S 2014) 8: Passw.-Hash 8.1: Key Stretching Iteration – Without Knowing the Count just let the user decide for herself

unknown iteration verify unknown iteration input: pwd, salt, N input: pwd, salt, N, X X ← H(salt, pwd) X 0 ← H(salt, pwd) while true do while X 6= X 0 do X ← H(salt, X) X 0 ← H(salt, X) end while end while when exception: {user: ctrl-c} accept return X when exception: {user: ctrl-c} reject

–236– Stefan Lucks Hash Fun. & PW (S 2014) 8: Passw.-Hash 8.1: Key Stretching Usage Scenarios for Password Scramblers

I user authentication

I key derivation

I proof of work

I ...

These uses imply different attack models / security requirements!

–237– Stefan Lucks Hash Fun. & PW (S 2014) 8: Passw.-Hash 8.1: Key Stretching History until 2010

1960s: Wilkes: plain passwords are bad → store hash and compare 1978: unix crypt I 25 iterations of DES-like operation I 12 bit salt to hinder dictionary attacks 1980s: shadow passwords I store (user, salt, dummy) in File A I store H(pwd, salt) in File B 1995: Abadi, Lomas, Needham: pepper 1997: Kelsey, Schneier, Hall, Wagner: analyzed iteration 2007: Boyen: unknown iteration count 2010: Turan, Barker, Burr, Chen: First standard for KDFs (PBKDF1/2 – Password-Based Key Derivation Function)

–238– Stefan Lucks Hash Fun. & PW (S 2014) 8: Passw.-Hash 8.1: Key Stretching Practical Password Scramblers and KDFs until 2010

1978: crypt: in UNIX-based systems based on DES (25 iterations), 12-bit salt 1995: md5crypt by Poul-Henning Kamp 64-bit salt, 1000 iterations of MD5 1995: bcrypt by Provos and Mazières based on Blowfish (Schneier, 1993) needs a significant (but constant) amount of memory: S-boxes (4 × 1024 Bytes) + subkey (72 Bytes)) 2010: PBKDF2 by NIST first standard for KDFs, can use hash function or block cipher

–239– Stefan Lucks Hash Fun. & PW (S 2014) 8: Passw.-Hash 8.1: Key Stretching PBKDF2 Password-Based Key Derivation Function Two F(pwd, salt, N, i) I F is the core function I PRF(Key, Input) is modelled U ← PRF(pwd, salt || i32) X ← U as a “pseudorandom for I ← 1 to N do function” U ← PRF(pwd, U)(∗) I Why is pwd used in every X ← X ⊕ U round? Isn’t that dangerous? end for I Should we replace line (∗) return X by U ← PRF(U)?

I PRF could be instantiated by

I a block cipher E: PRF(K , U) = EK (U) I a MAC M: PRF(K , U) = MK (U) I a hash function H: PRF(K , U) = H(K || U) I the HMAC-construction, using H in a nested way:

PRF(K , U) = H(K ⊕ const2 || (H(K ⊕ const1 || U))

–240– Stefan Lucks Hash Fun. & PW (S 2014) 8: Passw.-Hash 8.1: Key Stretching PBKDF2 can Generate Large Outputs relevant for key derivation

I For a required number of output bits, PBKDF2 concatenates F(pwd, salt, N, 1) || F(pwd, salt, N, 2) || ... truncating the ﬁnal call to F(pwd, salt, N, i) to the required number of bits I Example WPA2:

I PBKDF2 with PRF = HMAC-SHA-1 and N = 4096 iterations I output 256 bits, but HMAC-SHA-1 provides 160 bits I thus, call F twice

I use all the 160 bits from F(pwd, salt, N, 1) I and the ﬁrst 96 bits from F(pwd, salt, N, 2)

–241– Stefan Lucks Hash Fun. & PW (S 2014) 8: Passw.-Hash 8.1: Key Stretching 8.2: scrypt(Percival, 2009) The Advance of Massively Parallel Commodity Hardware

http://www.nvidia.com/object/what-is-gpu-computing.html

I commodity hardware with an abundance of parallel cores

I attacker can try out any number of password in parallel

I defender is hashing a single password

I also, defender does not always have so many cores

–242– Stefan Lucks Hash Fun. & PW (S 2014) 8: Passw.-Hash 8.2: scrypt Wisdom # 7: Storage is Expensive . . . use this, to make the adversary’s life harder CPU (Multiple Cores) GPU (Hundreds of Cores)

Core 1 Core 2

Core 3 Core 4

Cache Cache similar cache and memory sizes RAM RAM

Adversaries with cheap of-the-shelf parallelizable hardware (GPUs, FPGAs, ASICs, . . . ) do not have much memory – especially fast cache-memory.

–243– Stefan Lucks Hash Fun. & PW (S 2014) 8: Passw.-Hash 8.2: scrypt Memory-Hard Functions

I let f be a function which can be computed in time T using space S

I consider a machine with S/k units of memory, instead of S

I a function f is memory-hard if the time grows from T to kT , at least

Deﬁnition 10 A function f is memory-hard if computing f (x) with an input of size n needs S(n) space and T 0(n) units of operations, where S(n) ∗ T 0(n) ∈ Ω T 0(n)2−

for > 0.

–244– Stefan Lucks Hash Fun. & PW (S 2014) 8: Passw.-Hash 8.2: scrypt Sequentially Memory-Hard Functions

0 I note that the “time” T in the deﬁnition of memory-hardness only denotes the number of operations

I this does not rule out a c-times speed-up when computing f (x) on a machine with c parallel cores

I we would like to stick with an actual time T /k, given any number of parallel cores

Deﬁnition 11 A function f is sequentially memory-hard if (1) it is memory-hard and (2) it cannot be computed on a machine with S(n) processors and S(n) space in expected time T (n), where S(n) ∗ T (n) = O T (n)2−

for any > 0.

–245– Stefan Lucks Hash Fun. & PW (S 2014) 8: Passw.-Hash 8.2: scrypt The Outer Layer of scrypt

scrypt (pwd, salt, N) B ← PBKDF2(pwd, salt, 1) B ← ROMix(B, N) B ← PBKDF2(pwd, B, 1) return B

I ROMix is the core operation (see below)

I framed by two calls to PBKDF2 (HMAC-SHA-1 and one iteration)

I input B of ROMix is password-dependent

I postprocessing needs the pwd again (ﬁx: use zero string, instead)

–246– Stefan Lucks Hash Fun. & PW (S 2014) 8: Passw.-Hash 8.2: scrypt ROMix, the Core of scrypt

ROMix(B, N) X ← B for i ← 0 to N − 1 {initialize V0,..., VN−1} do Vi ← X X ← H(X) end for for i ← 0 to N − 1 {read V0,..., VN−1 at random points} do J ← X mod N X ← H(X ⊕ Vj ) end for return X

I ROMIX uses a complex “BlockMix” operation, for H, based on the stream cipher SALSA20/8. But one can use any good hash function, instead.

–247– Stefan Lucks Hash Fun. & PW (S 2014) 8: Passw.-Hash 8.2: scrypt Properties of ROMix

Theorem 12

1. Given sufﬁcient storage for all the N values Vi , ROMix can be computed in time O(N).

2. Given sufﬁcient storage for N/k of the Vi , ROMix can be computed in time O(kN). 3. ROMix is sequentially memory-hard.

(For proof sketches, see the blackboard.)

–248– Stefan Lucks Hash Fun. & PW (S 2014) 8: Passw.-Hash 8.2: scrypt Wisdom # 8: Guard the Backdoor . . . and protect your password-scrambler from side-channel attacks

Same bad news for scrypt:

I ROMix is vulnerable to cache-timing attacks.

I ROMix is vulnerable to garbage-collector attacks.

(See the blackboard.)

–249– Stefan Lucks Hash Fun. & PW (S 2014) 8: Passw.-Hash 8.2: scrypt