LastPass Key Derivation Security Question

Question

I have done some research about password managers and of course stumbled upon LastPass. There are plenty of questions and answers about the security of LastPass, but as far as I am aware none of them talked directly about this specific implementation. When I read this I was quite surprised

LastPass has opted to use SHA-256, a slower hashing algorithm that provides more protection against brute-force attacks. LastPass utilizes the PBKDF2 function implemented with SHA-256 to turn your master password into your encryption key. LastPass performs x number of rounds of the function to create the encryption key, before a single additional round of PBKDF2 is done to create your login hash.

This is how it should work (if understood correctly) according to their Website

1. Use PBKDF2 on the Master-Password, with the username as salt
2. Iterate at least 5000 times (or higher if configured)
3. Master Key is the result of the iterations
4. Do one additional round of PBKDF2 and send this to the server for authentication

5. Server does additional 100.000 rounds of PBKDF2 with a different salt & scrypt with unknown parameter since the security breach

6. Store and/or compare in/with Database (use HSM for some part here or under 5.)

7. Send reply to client with vault (encrypted)

8. Client decrypts with Master Key

While in theory everything is nice and secure, we know LastPass had security breaches in the past. The Master Key is only hashed one more round before being send to LastPast. Assuming that an attacker could potentially get access to LastPass infrastructure and read the values received before step 5.), does this significantly endanger the Master Key?

I would think maybe, but we cannot do a dictionary attack on the key, so the classic attack vector on PBKDF2 does not apply. Unless we have really strong custom hardware, so that we can do a dictionary attack on the master password, despite the 5000 rounds. But on the other hand being just one round away from the Master Key seems a little too close for comfort.

Is there any realistic threat for the Master Key under such circumstances?

Answer 1

First, keep in mind that 99.99...% of sites transmit your password to the server in clear-text over (over an SSL connection, of course). There the server actually has your clear-text password during authentication. So even that one hash increases security.

Taking a step back, the reason that we perform numerous rounds for hashing or key derivation for passwords is that we are going from a relatively small set of possible inputs (ie: passwords chosen by us dumb users). As the set size is small, you need to increase computational expense of a dictionary or brute-force attack by making the calculation of each hash (much) more costly. We do this by repeating the hash over and over.

In the Lastpass situation that you ask about, the input to the hash is the output of another hash. So the input space is relatively well distributed across the full 256 bits. At least it will be after you salt the passwords (without salt this would be susceptible to a pre-compute attack). That means that a brute-force attack would have to test the full 256 bit space to reverse the one hash. This is too large for precomputation attacks (eg: use of rainbow tables).

Now if an attack is developed that allows you to reverse SHA-256, that would increase the risk in this situation, along with many, many others.