It's also not really an obscure issue. For example, the owasp password cheatsheet talks about the need to increase the work factor over time - https://cheatsheetseries.owasp.org/cheatsheets/Password_Stor... . I would hope that password manager software would at least know the things that end up on "cheatsheets"

Why is this even a setting exposed to users? Shouldn’t this be entirely up to them to manage the correct work factor?

100% agreed. Paying for a major brand password manager, you should assume that you are paying for them to always keep the security totally up-to-date with best practices. The idea that you are somehow responsible for finding an obscure setting not just in "Account settings" but in a separate "Advanced settings" that defaults to hidden, and knowing the appropriate number to set it to, boggles the mind.

Paying? What is this "paying" you are talking about?

“But look, you found the notice, didn’t you?”

“Yes,” said Arthur, “yes I did. It was on display in the bottom of a locked filing cabinet stuck in a disused lavatory with a sign on the door saying ‘Beware of the Leopard.’”

There’s an entire novella of Arthur just finding this notice, right? It could be serialized into three one hour episodes of Dent, queuing & requeuing and just talking to others inqueue.

Bc product people are hilarious!

Why not both?

Keep in mind that this is a trade-off, it requires more computational power AND battery, so giving users access to the leavers makes sense (e.g. power users with nice equipment can pump up the number).

That being said I do agree that it is up to the vendor to set AND enforce a new higher minimum. If someone logs in with 5K rounds, it should be changed to the new default (100k).

On a related note Bitwarden also allows users to configure this. I recently increased mine to 150K rounds.

I think it should allow you to change the schedule on which it increases the rounds, not set the actual number. It should tell you how many rounds it currently is at and how it will increase but the setting most people will want is High Security, Very High Security, Ludicrous Security.

Having the controls is great if you’re a technical person who knows what to do with them.

99.9%+ of people aren’t that technical person. Safe defaults need to be used and kept up to date for them.

Because changing the number of rounds requires reencryption and it doesn't sound like they had a workflow for prompting batch reencryption other than through the setting.

Ideally they'd manage that number and prompt the user to change it over time.

It's not that difficult to do though? Just implement a mechanism that re-encrypts when the user enters their password.

I agree, there's workflows they could've built to solve this problem. I wasn't defending them in the slightest.

It's because bikeshedding emphasizes customization and easy to demo features over the type of design that actually helps most users.

Because different hardware will have significant impact on this number. You need to figure out your tolerance. Maybe your tolerance is higher than they expect - cool, bump it up. I did that many many years ago, thankfully.

Yeah I was a daily user until about a month or two ago. Didn't even know about this setting, and I still haven't figured out how to change it in the mobile app. But mine is definitely set to 5k. Still in the process of changing all my passwords...

This is pretty wild. When you rotate your master password and it re-encrypts everything, that's a perfect opportunity to use a new iteration count. If they didn't want change the value for user's who were at an old default value, they at least could have nagged "your account is using an old/low value for an encryption setting, click here to use the latest recommended default"

Of course, changing it now won't do any good with regard to previous leaks.

They could have changed the setting any time the user logged in. I pointed out that they used too few rounds over a decade ago, I believe. To their credit, they increased the limit to 256K in response (it was much lower before).

Yup mine was 5000 too. I'm baffled as to why they don't force an upgrade on everyone the next time they log in.

Old accounts that haven't been touched in years, sure. But active accounts being used daily? This is really unfathomable.

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

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

Mine seem to be set to 1 iteration, screenshot here: https://snabelen.no/@vegardlarsen/109575002998425618

My account is very old, but this was hidden behind advanced settings. And I have used this account daily since I created it. Not having this increase from their end seems very unprofessional.

Mine was also set to 5000

I have a really old account (pretty sure I started using it ~2010) and I use lastpass essentially daily. I've never looked at that setting and I see that mine is set to 100,100. So it's migrated sometime. But I do also have some vague memory of a lastpass incident years ago where there was a prompt that they wanted to re-encrypt everything preemptively.