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.

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.)

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.

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.

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.

> 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

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.

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.

> 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.