[tptacek]

I find this design kind of baffling. Why go through the trouble of storing data encrypted only to snatch defeat from the jaws of victory by demanding that the client provide a secret derived from the encryption key just to log in?

[eric_the_read]

I finally managed to convince my mother to start using LastPass recently; if I'd had to convince her to use two "master" passwords-- one for the encryption key, one for the service-- I'm fairly sure she'd still be using Google Contacts to store her secrets. :-\

[Someone1234]

Exactly. Why is why I entirely understand LastPass's reasoning for not doing that by default. But it would be a nice "advanced user" option (like 2F and all the other toys hidden in the account settings advanced tab).

[harshreality]

I suppose they need to ensure that the person logging into the site, or interacting with the site via the browser extension, actually created the encrypted archive. Without a passphrase-derived authentication token (which they say is something like pbkdf2(encryption_key + passphrase), where encryption_key itself is pbkdf2(email + passphrase)), how could they ensure that?

Without that connection, if they had a totally separate secret S for web logins, anyone with S (and your 2-factor token if you have it enabled) could change your server-stored archive with no knowledge of how to decrypt it. Wouldn't that be a denial of service attack, if the next time you login to lastpass your local encrypted password archive is overwritten? You'd then have to rely on whatever other backup solution you (hopefully) use, to get an old local copy of the encrypted password archive.

[aptwebapps]

That's true, but you have a local copy by default. I'm not sure what happens if the local and the server copy get radically out of sync - I don't know if it would purge your local copy or not.