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.
Edit: I should add that I have logged into this account within the past year or two. So if they're supposed to increase over time, it ain't worked.
“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.’”
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.
99.9%+ of people aren’t that technical person. Safe defaults need to be used and kept up to date for them.
Ideally they'd manage that number and prompt the user to change it over time.
Of course, changing it now won't do any good with regard to previous leaks.
Old accounts that haven't been touched in years, sure. But active accounts being used daily? This is really unfathomable.
Well, No. In metacode, pbkdf2 works something like:
derived_password = pbkdf2(real_password, salt, 5000, ...);
Encrypt(vault, derived_password);
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.
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.)
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.
I've done this with normal login for several (legacy) systems I've worked on, migrating users from md5 or sha1 to better algorithms.
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.
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.
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)
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
email, salt2, hash2(hash1(master_password, salt1), salt2), salt1
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)
email, new_salt, hash2(master_password, new_salt), NULL
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.
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.
You aren't wrong, if true that's certainly a mistake on their part. Practically speaking though as long as the passwords are randomly generated it probably doesn't matter, i.e. if you think about what the IV and chaining are doing in CBC. ECB is just as good for encrypting a random stream of bits; CBC just makes sure the bits are random before passing them into the cipher. Of course the optics are still terrible.
1. In real life, passwords aren't random. Password manager users are probably less likely than average to make this blunder, but I'd still be willing to bet _the majority_ of lastpass's customers do.
2. Even if you personally have all random passwords, would you really want to use a product made by people who made this level of a noob mistake? I used to pay for LastPass premium, now my account is deleted, my passwords are changed, and my money goes to Bitwarden instead - and every time I hear about Lastpass I don't regret this decision.
Obviously this isn't an endorsement of LastPass. Everything about their protocols is disappointing. Even if the encryption issues turn out to be of the well-that-was-a-dumb-choice-but-you-don't-need-to-panic variety, it's because they got lucky, not because they were good.
Maybe I wasn't obvious enough, but this is the problematic assumption. When I say "non-random password", that's what I mean: a reused password.
Almost everyone I know reuses passwords (sometimes with a slight variation, but 90% of the password the same), and my day job is a software engineer. I'd be willing to be at least half of Lastpass's users have at least 1 reused password.
Kind of a long shot though.
If you have some attacker after specifically you, yes this information is of less use to them, because they will have tried every password of yours they have on every website already hoping you reuse passwords.
If the attacker doesn't have the valid password, the knowledge that two different sites share the same password isn't exactly game-changing.
To an outsider, hearing people talk about how LastPass used Very Bad ECB mode makes it sound like a fuckup with immediate and dramatic effect on the security of their passwords, that isn't exactly true.
Nobody should have been using LastPass, but we can still be realistic about the threats facing those who did.
> but the obvious problem here is the offline cracking of the vault passwords; this isn't worth arguing about.
Of course not, but that's a completely separate issue from their choice of AES mode.
The reason I suspect even non-random passwords might be mostly fine[1] is because there's no oracle and passwords are generally short. There's not much there for someone to hang their hat on. It's only a hunch, though; if tptacek for example says something different, I'd believe him.
1. Meaning: No need to cancel Christmas. You can deal with it later. Not meaning: ECB is as strong as CBC or whatever.
i have been using keepass(xc) since it's been around and i dont use random passwords. every year i create a formula that creates all my passwords and i put these in the vault. it also enforces password rotation. losing the vault i can still come up with any of my psswords just by remembering the formula.
for company server services it's a different story, i generate wholly random strong passwords and story them in the offline vault.
You need to know the specific order how to create the password for a new site. Otherwise it was just easier to plow through with your favourite memorised combination.
At least I found it hard to do with Lastpass on mobile. Now I’ve tested it with Bitwarden and 1Password 8, they seem to do a better job with it.
This allows an attacker to detect repeating plain text segments, e.g. reused passwords.
The Wikipedia article on block cypher modes illustrates this problem rather well [1].
[1]: https://en.wikipedia.org/wiki/Block_cipher_mode_of_operation...
Also, I've just learned that the quintessential file has been recently replaced. I understand the need for a higher resolution file, but I'm still a bit sad.
This is hardly a problem, any login form will also allow an attacker to do this.
CTR is not a very robust block cipher mode...
Have they not heard of the first rule of crypto being "You probably aren't qualified to do it, use libsodium or TLS or SSH" yet? Why are they messing with cipher modes themselves?
a) LastPass is extremely old
b) Browser extensions used to be completely different. You needed to call out to native code to do tons of stuff because the JS apis were extremely limited and slow. So it was either "roll crypto in JS" or "make users install a binary", the latter stopped being possible over something like a decade ago.
For this particular use-case? Hardly.
Since an attacker can easily use any login form of their choice as an oracle for password reuse, ECB mode can't really introduce significant issues here.
If the attacker has an encrypted vault, what is the login form there for them to use and detect password reuse?
Incorrect password attempts are essentially free, so ECB revealing reuse does not meaningfully help the attacker.
But for the attacker to try one of my passwords in a login form, they do need to have that password cracked already, which means that they already have my master password. But if they have that, they can decrypt all of my passwords, and the login forms are of no use.
Am I misunderstanding something here?
No, not at all. The point is that while ECB is a silly choice, it does not make it easier for the attacker to crack your vault. It does allow the attacker to see if you're reusing passwords, but does not reveal to the attacker what those passwords are.
On the other hand, If the attacker were to discover one of your passwords from another source, they'd be able to confirm reuse anyway by simply attempting to use that password on other websites.
The point is you explain why you do this. Start the message with "We care about your encryption" and go from there to explain that they need you to upgrade because the don't know your master key, they need your help to do it.
Adding this kind of behavior should be their core business. Apparently it's not.
Kind of unclear but i think this implies that lastpass doesn't do some and reencrypt on login. Are they saying its just people who havent unlocked there vault in a decade, or are they saying all old users have this? If the latter this is really poor design.
> Lots of vault entries may be encrypted with ECB mode AES-256.
Wtf wtf wtf. This would be considered wildly insecure even by the standards of the 80s