Hacker News new | past | comments | ask | show | jobs | submit login

1Password only stores encrypted files in Dropbox. The encryption is done offline. Assuming the encryption is done properly, it is difficult to conceive of a way to attack it even assuming that Dropbox is compromised.



Actually that's how LastPass works (they move around an AES-256 encrypted database, and decrypt it on the client/browser).

The problem LastPass has, is that they re-use the same master password for two distinct things:

- Authenticating to login to your account.

- Encrypt your password database.

So in situations like this the loss of the authentication hash is relevant. I'd prefer to have a different password for the account than the database, but they don't offer that as far as I know.

In general I am broadly happy with LastPass's security. But it could be a little better for power users.


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?


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


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


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.


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.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: