3 ms·

> Seems weird that they would have the number of rounds fixed from the time of account creation though. Surely it would be possible to increase the number of ro

> Seems weird that they would have the number of rounds fixed from the time of account creation though. Surely it would be possible to increase the number of rounds over time. Well, No. In metacode, pbkdf2 works something like: derived_password = pbkdf2(real_password, salt, 5000, ...); Encrypt(vault, derived_password); (See Wikipedia for more details https://en.wikipedia.org/wiki/PBKDF2 https://en.wikipedia.org/wiki/PBKDF2) Point being, you can only change the number of rounds if you re-encrypt the vault, and you can only do that, if the users participates by giving their password to first un-encrypt it during that process. So it cannot be done silently in the background.

mvonballmo 4y ago
Agreed, it requires user-participation. However, LastPass could be proactive about this, perhaps including the number of rounds in its security check. It could tell you that your legacy account should be updated and guide you through it. That would be helpful. I have the standard 100,100 iterations, but had no idea that this was a feature I had to keep track of.
gregmac 4y ago
It's possible to silently do this as part of logging in. I've done this with normal login for several (legacy) systems I've worked on, migrating users from md5 or sha1 to better algorithms.
- d1str0 4y ago
  Theres a big difference. If you’re hashing a password for storage you end up getting the password first. LastPass NEVER gets your master key server side. All encryption is done locally. Also, hashing a password is extremely quick. To unencrypt the full vault and re-encrypt it does take an amount of focused time. Might not be able to be done “silently” in the background, but obviously LP should have been forcing an upgrade on login.
  - coder543 4y ago
    > To unencrypt the full vault and re-encrypt it does take an amount of focused time. The entire vault should not be encrypted directly with the user's password. That would go against standard best practices. See this comment written hours before yours, right under the comment you replied to: https://news.ycombinator.com/item?id=34127993 https://news.ycombinator.com/item?id=34127993 There is no "big difference" here, and it could be done trivially during login. The fact that it would be done client side instead of server side is a very minor implementation detail.
jchw 4y ago
You don't need to re-encrypt the entire vault, just whatever you're using the PBKDF2-derived key to hide. In most situations, you'd use it to encrypt another, separate key. In that case, it can be readily upgraded at any time, including during login. Conceptually, it's not very different from how password hashes are updated, just that you need to re-wrap some other key as well simultaneously. Since the rest of the vault is unaffected, it's OK if the transaction fails: the old parameters will work with the old wrapped key, so all you need to do is ensure that the transaction is atomic. (Usually don't even have to do anything to ensure that if you just use the same database table/object.)
- deleted 4y ago
  [deleted]
- unscaled 4y ago
  The original vault format seems pretty badly designed (unencrypted URLs, low-ish number of rounds even for the time, and of course ECB). With this shoddy design, it's hard to expect the developer to be smart enough to add an intermediate random key. And it's probably a good thing the original design didn't have that — I'm pretty sure Crypto.getRandomValues() wasn't available on all browsers yet when LastPass was first release it's JavaScript version (not sure when that was — I've never been a LastPass user). Of course, the format itself can also be (and should have been!) transparently upgraded. Interrupting legacy users just once for a 20-30 second upgrade of their entire vault is a no-brainer. The fact that LastPass hasn't proactively upgraded old vaults on login during all these years reflects very badly on their security.
Philip-J-Fry 4y ago
I'm aware you can't do it silently in the background. But they can prompt the user to input their password. And you're already prompted when signing in on different devices or at regular intervals when the vault locks. Seems fairly easy to me from a UX point of view.
tzs 4y ago
> Point being, you can only change the number of rounds if you re-encrypt the vault, and you can only do that, if the users participates by giving their password to first un-encrypt it during that process. So it cannot be done silently in the background. I think there might be a way to update it without having to wait for the user to supply the master password, at least if their web login works like most, although it would require some additions to the database and their server side vault storage. According to the documentation I found the master password you create when you make your account is the master for both logging in to your account and for encrypting your vault. To handle its use as a login password they probably have a table somewhere that contains: email, salt1, hash1(master_password,salt1) I'll assume that they want to update both the login password hashing difficulty and the vault decryption difficulty. To handle updating login hashing they could change that table to contain for accounts that have logged in or been created after the difficulty change: email, salt2, hash2(master_password, salt2), NULL and for accounts created before the change that have not yet logged in: email, salt2, hash2(hash1(master_password, salt1), salt2), salt1 For the vault storage, they'd have to change it so that instead of just singly encrypted vaults, Encrypt(vault, derived_pass), it can also store doubly encrypted vaults, Encrypt(Encrypt(vault, derived_pass), derived_pass2). When they do the change, they would change existing vaults to double encrypted, with derived_pass2 = hash1(master_password, salt1). When someone logs in for the first time after the change, they supply master_password. The server would see from the login hash table that salt1 is not NULL meaning they are an un-upgraded account. It could then compute temp = hash1(master_password, salt1) pwhash = hash2(temp, salt2) and see if that matches the hash in the login hash table. If it does the login is successful, and it can (a) generate a new salt and update the login hash table to contain: email, new_salt, hash2(master_password, new_salt), NULL and (b) use hash1(master_password, salt1) to remove the double encryption from the vault, use master_password to decrypt the vault, and then re-encrypt with a new derived password with the new upgraded work factor. NOTE: the above is based on documentation of theirs that says you use the master password for logging in to your account. However other documentation of theirs says that the master password is never sent to their servers.

mvonballmo 4y ago

Agreed, it requires user-participation. However, LastPass could be proactive about this, perhaps including the number of rounds in its security check. It could tell you that your legacy account should be updated and guide you through it. That would be helpful. I have the standard 100,100 iterations, but had no idea that this was a feature I had to keep track of.

gregmac 4y ago

It's possible to silently do this as part of logging in. I've done this with normal login for several (legacy) systems I've worked on, migrating users from md5 or sha1 to better algorithms.

d1str0 4y ago
Theres a big difference. If you’re hashing a password for storage you end up getting the password first. LastPass NEVER gets your master key server side. All encryption is done locally. Also, hashing a password is extremely quick. To unencrypt the full vault and re-encrypt it does take an amount of focused time. Might not be able to be done “silently” in the background, but obviously LP should have been forcing an upgrade on login.
- coder543 4y ago
  > To unencrypt the full vault and re-encrypt it does take an amount of focused time. The entire vault should not be encrypted directly with the user's password. That would go against standard best practices. See this comment written hours before yours, right under the comment you replied to: https://news.ycombinator.com/item?id=34127993 https://news.ycombinator.com/item?id=34127993 There is no "big difference" here, and it could be done trivially during login. The fact that it would be done client side instead of server side is a very minor implementation detail.

jchw 4y ago

You don't need to re-encrypt the entire vault, just whatever you're using the PBKDF2-derived key to hide. In most situations, you'd use it to encrypt another, separate key. In that case, it can be readily upgraded at any time, including during login. Conceptually, it's not very different from how password hashes are updated, just that you need to re-wrap some other key as well simultaneously. Since the rest of the vault is unaffected, it's OK if the transaction fails: the old parameters will work with the old wrapped key, so all you need to do is ensure that the transaction is atomic. (Usually don't even have to do anything to ensure that if you just use the same database table/object.)

deleted 4y ago
[deleted]
unscaled 4y ago
The original vault format seems pretty badly designed (unencrypted URLs, low-ish number of rounds even for the time, and of course ECB). With this shoddy design, it's hard to expect the developer to be smart enough to add an intermediate random key. And it's probably a good thing the original design didn't have that — I'm pretty sure Crypto.getRandomValues() wasn't available on all browsers yet when LastPass was first release it's JavaScript version (not sure when that was — I've never been a LastPass user). Of course, the format itself can also be (and should have been!) transparently upgraded. Interrupting legacy users just once for a 20-30 second upgrade of their entire vault is a no-brainer. The fact that LastPass hasn't proactively upgraded old vaults on login during all these years reflects very badly on their security.

Philip-J-Fry 4y ago

I'm aware you can't do it silently in the background. But they can prompt the user to input their password. And you're already prompted when signing in on different devices or at regular intervals when the vault locks. Seems fairly easy to me from a UX point of view.

tzs 4y ago

> Point being, you can only change the number of rounds if you re-encrypt the vault, and you can only do that, if the users participates by giving their password to first un-encrypt it during that process. So it cannot be done silently in the background. I think there might be a way to update it without having to wait for the user to supply the master password, at least if their web login works like most, although it would require some additions to the database and their server side vault storage. According to the documentation I found the master password you create when you make your account is the master for both logging in to your account and for encrypting your vault. To handle its use as a login password they probably have a table somewhere that contains: email, salt1, hash1(master_password,salt1) I'll assume that they want to update both the login password hashing difficulty and the vault decryption difficulty. To handle updating login hashing they could change that table to contain for accounts that have logged in or been created after the difficulty change: email, salt2, hash2(master_password, salt2), NULL and for accounts created before the change that have not yet logged in: email, salt2, hash2(hash1(master_password, salt1), salt2), salt1 For the vault storage, they'd have to change it so that instead of just singly encrypted vaults, Encrypt(vault, derived_pass), it can also store doubly encrypted vaults, Encrypt(Encrypt(vault, derived_pass), derived_pass2). When they do the change, they would change existing vaults to double encrypted, with derived_pass2 = hash1(master_password, salt1). When someone logs in for the first time after the change, they supply master_password. The server would see from the login hash table that salt1 is not NULL meaning they are an un-upgraded account. It could then compute temp = hash1(master_password, salt1) pwhash = hash2(temp, salt2) and see if that matches the hash in the login hash table. If it does the login is successful, and it can (a) generate a new salt and update the login hash table to contain: email, new_salt, hash2(master_password, new_salt), NULL and (b) use hash1(master_password, salt1) to remove the double encryption from the vault, use master_password to decrypt the vault, and then re-encrypt with a new derived password with the new upgraded work factor. NOTE: the above is based on documentation of theirs that says you use the master password for logging in to your account. However other documentation of theirs says that the master password is never sent to their servers.