LastPass has not responded to my questions asking what is encrypted.
Nevertheless, this post lends credence to the belief that the notes portion of a Password Item is encrypted; scroll down to the section titled “Structures of some types of composite data blocks.”
Dave…Enpass is currently the leader for me if when 1Password v7 quits working. I like the DropBox sync and dislike the subscription requirement…plus I want the ability to my own backups. The security with Bitwarden is probably a little better with the fingerprint phrase and the reencryption on their servers of the already encrypted on your device vault…but with 100,000 rounds of encryption then as long as one has a long password on both Enpass and Dropbox it’s really good enough…as Enpass only uses the cloud for sync and decryption is only on device.
My wider family say this to me: “they are not interested in little old me and won’t spend the time”. While the value of your data may not be great, I know some of theirs is.
One response is that they (the thieves or the people they sold your data to) don’t spend the time, they just throw your data at bots and get on and do other stuff. If the bots turn up something interesting, even mildly profitable…woohoo!
Rob
This is why I have never used a password manager.
Absolutely correct. Which is why it’s important to know how they’ve encrypted your data and who holds the key.
If the service provider doesn’t have the key and it is known to be strong (long bit-length and either randomly-generated or generated from a strong passphrase), then any attack will require brute-force, which will take too much time for them to bother with.
Bots or not, they won’t want to spend a long time (probably not even on the order of hours) trying to crack a strong key when they could instead spend that time attacking hundreds of other accounts, some of which will have a weak key that they can quickly crack.
It’s like the old joke. I don’t need to be faster than the lion. I only need to be faster than you.
Granted. But I was specifically referring to the effort/cost to force-decrypt my data. Of course the bad guys have “bots” to do this, but my point is that a big enough “bot” to do the job would cost many orders of magnitude more money than the perps could reasonably expect to recoup from me, and it would still take more time to complete than they could reasonably expect to live.
As mentioned on another thread, I’ve been trialing Enpass for about a week now. So far, I like it. I’m using the iCloud sync option, and once I got the vault locking interval down to something that works for me, it’s only slightly annoying (but much more so than LastPass) when you need to unlock. To their credit (and another differentiator from LP), they default to locking the vault very quickly, and you need to dial that back to the level that makes sense for you. So far, +1 for Enpass.
That’s troubling. Just try again, perhaps from another device, and see what happens. I was set to 100,100, but for giggles, I tried changing it to 333,000. That succeeded but a day later when I went in, I was dismayed to see it was set to 333 instead. I changed it again to 200,000, and confirmed after the fact that that stuck
I think you will need log in again on each device, which will do the update. I can’t quite say for sure because I’ve been doing a bunch of things, but I definitely had to fuss with LastPass on multiple devices.
LastPass PR hasn’t replied to me about that either.
LastPass says nothing about having to change the PBKDF2 iterations on each device.
As I understand it, every encrypted portion of the Vault must be re-encrypted when the number of iterations is changed. And obviously, the resulting Vault is then incompatible with every copy of the previous Vault. So, those old copies of the Vault must be replaced with the new one.
I’d guess—but have not verified—that simply logging out of a device and then logging back in would replace the old Vault with the new one (downloaded from LastPass’ server). If so, then there is no reason to change the number of iterations on each device. You just have to log out of each device and log back in to synchronize the Vaults on all your devices (with one re-encrypted with the new number of iterations).
As I understand how LastPass uses PBKDF2, increasing the number of iterations has no effect on the stolen Vault.
Yes, but if you are going to continue using LastPass, it’s an important thing to change ASAP.
Yep, that’s my understanding as well. I don’t think there was any suggestion that you’d need to change the setting on every device—it’s an account setting, not a device setting.
I use the older, less common, but functional PasswordWallet app. My only frustration with it is that syncing between devices doesn’t stay up-to-date automatically. So sometimes on my my iPhone and need to manually do a sync to get the latest password. But it works, and it’s not subscription based. Aren’t the others subscription based now?
Thanks to everyone for all the feedback. After logging out of LP on all but one mac, I changed the iterations successfully to 100100; this only took about a minute, and did populate to my other macs/phone when I logged back in on them. I’ll report back tomorrow if the change doesn’t stick (as happened to Adam earlier). Many thanks to all.
The Washington Post help desk column was actually quite good. So often the big media papers get these somewhat wrong. (This should not be behind the paywall.)
While the general drift of that article is excellent, I’m not sure I’d take much security advice from a columnist who stores their password manager password on a piece of paper in their wallet! Yikes.
But what is the marginal value of increasing the number of iterations beyond a thousand?
My understanding is that there are only two benefits of PBKDF2:
For online attacks, wouldn’t LastPass notice even just 100 consecutive failed attempts to access a Vault and then prevent additional guesses. Does making each guess take longer make any difference for good passwords if LastPass limits the number of guesses?
For offline attacks of Vaults with good passwords, I don’t understand why PBKDF2 has any value at all. If the password is good enough to force a brute force attack in a huge search space, why is there any need to salt and hash each guess of the Master Password? Why wouldn’t the attacker just guess the the key itself as opposed to guessing the Password and then iteratively salting and hashing it?
Perhaps someone can explain why a large number of PBKDF2 iterations is anything other than a distraction from what really matters, namely, creating a Password that is vulnerable to nothing other than a very lucky guess among a vast number of possibilities.
UPDATE January 11, 2023 12:53 PM
See @ddmiller‘s response. I stand corrected regarding off-line attacks.
Lastpass uses SHA-256 bit hashing, so it would take on average 2 to the 255th guesses to get the resulting key (half of 2 to the 256th number of possible keys). That’s a lot more bits of entropy than what is likely a memorable master password, and even with key stretching iterations to slow down guesses with something like PBKDF2, brute force guessing of the password will be faster. (It should also be noted that there could be a hash collision between different passwords so it’s possible to guess the wrong password and still be right, but it’s a very remote chance.)
Funny you should ask. This was a discussion in the Firefox Bugzilla: 1320222 - Review FxA client-side key stretching parameters
A quick summary is that there’s a request to review the number of iterations (currently 1000), and considers increasing it to hundreds of thousands of iterations.
The argument is that 1000 was originally chosen in order to run reasonably fast on the hardware of the time and now we have much faster hardware that can handle more iterations without imposing a significant delay on the user.
The counter-argument is that it won’t really help. An attacker who can get by the TLS encryption (of the HTTPS connection) shouldn’t be able to extract the plaintext password from what he sees. For this purpose one iteration of PBKDF2 will be sufficient - more iterations may add a slight delay, but won’t have any significant impact on the attacker.
For other purposes (beyond intercepting the TLS stream), it all comes down to thwarting the brute-force attack. More iterations means each try takes longer. If you require so many iterations that it requires 1/2 second to generate a key from a password, then even a short password (e.g. 6 same-case characters) will take a long time to crack (about 5 years for 6 characters at 2 per second).
But chasing that goal is ultimately going to be futile. As the attacker’s computer gets more powerful (and leasing time on cloud services is no big deal these days - so he potentially has a lot of available power), the number of iterations is going to need to constantly be increasing in order to keep pace. And every time it does, the data needs to be re-encrypted (not trivial overhead if it happens a lot, and very inconvenient for users).
But if the master password used to generate the various other keys and tokens is already secure (long and complex), then it no longer matters that much. As one commenter wrote:
So just keep your passwords long and complex and don’t worry much about how much hashing and re-hashing is being performed against it. Even a small amount of hashing should be sufficient if it is, and extreme amounts won’t help very much if it isn’t.
Here’s one more reason to ditch LastPass: It seems to be a product of LogMeIn, which has a D- rating in the BBB. They have a history of making it very difficult to unsubscribe from their services and continuing to charge people for discontinued accounts. This has been my experience, too, not with LastPass, but with GoToMeeting.