4

While reading about LastPass' breach, I was wondering why would LastPass store strengthened password hashes at all on the server side? Could they only store the AES encrypted data and when the user gets his encrypted data he could do the password strengthening + decrypt it and re-encrypt all on the client side so the only information LastPass is ever exposed to is the AES 256-bits encrypted data and that would be the only thing they would store in case of a breach.

As I write this post, I'm thinking that perhaps that stored hash is part of the authentication step to not give the AES encrypted data to anyone, but would that be the only reason to store the hash on the server?

Assuming that there's an alternate method to authenticate specific encrypted data to the user trying to access it, e.g. a shared random string between client and server not derived from the master password stored on the server side, could the hashing/password strengthening + encryption/decryption then be all done on the client side with no need to store anything else on the server side than the AES 256-bits?

Because wouldn't it be easier for someone to deduce the password from the hash alone than from the final AES encrypted product that was encrypted with that strengthened password hash? My guess is that the AES encrypted data would take longer to break than its hash alone just because of the extra step of computing the hash and then encrypting. So wouldn't that be another point for not storing the strengthened hashes on the server no matter how complicated the hashing algorithm is since it is a function of the master password.

Wadih M.
  • 1,102
  • 6
  • 20

2 Answers2

2

Yes, you're right - the hashed value is for authentication so that the encrypted data is not given out without the correct credentials being supplied to the service.

Another similar service, Roboform, does have different authentication and decryption passwords for each account. However, there was a serious flaw that when the web interface was used - the master password was sent to Robofom, even though they were not meant to ever receive it.

See this answer for full details of the LastPass authentication and encryption process, albeit being derived from the Security Now podcast.

From these details, my best guess is that the LastPass decryption key is calculated by:

DK = PBKDF2(HMAC-SHA256, password, email, <user set>, 256)

and the authentication key provided by the client JavaScript or application before LastPass service gives you access to your encrypted blob:

AK = PBKDF2(HMAC-SHA256, DK, password, <user set>, 256)

However, this is stored hashed on their backend:

Stored_AK = PBKDF2(HMAC-SHA256, AK, salt, 100000, 256)

As you can see, there is an awful lot of work to be done in order to get from the cleartext password into the form that the hash is stored in on the backend. The number of client side rounds (as indicated by <user set>) can also be increased, depending on the capabilities of each user's least powerful device, this is then hashed again on the client, and finally hashed server side before comparison with the stored hash. This means there's still an awful lot of work to do should an attacker gain access to the server stored hashes (as they may have already done).

Community
  • 1
SilverlightFox
  • 33,408
  • 6
  • 67
  • 178
1

The compromised hashes were used to authenticate the user.

The investigation has shown, however, that LastPass account email addresses, password reminders, server per user salts, and authentication hashes were compromised

If you don't want to give the encrypted data to everyone, you have to do some kind of authentication. Of course there could be a second password which is used to decrypt the data and of course it could be done on the client side. But this would raise the question why theres a need for a service like LastPass since the serving of encrypted data could be done using any kind of online storage.

This is a typical case of a user comfort vs security trade-off.

Noir
  • 2,523
  • 13
  • 23