You trust Dropbox? The company that infamously invited to their board a former government official responsible for authorizing warrantless mass surveillance?

My company forced us to use Box and actively blocks Dropbox on all work computers. They did an audit and didn’t like what they saw in Dropbox.

i think “trusting dropbox more” is not what i would necessarily expect.

nonetheless i think the provider of my password manager should not themselves host my password vault.

If anyone from 1password is reading this: I trust you, but you make it hard to do so if you cannot be flexible about not hosting everything.

fd: I use 1password at home and for work.

How would you run a shared vault for work on a „dumb“ file hosting service? With the ability to add/remove team members, recover vaults in case of password loss etc? What about the fact that master passwords can be brute forced if they are weak, just as LP customers are now affected?

I mean, crypographically we’ve had solutions to those exact problems for 30 years.

PGP might not be very usable but it also had mechanisms to do this.

if you are scared of people copying the vault before they lose access to the storage: you’ll be very sad to know that this is already possible with the SaaS solutions.

if you're worried about people breaking the vault if they have access: then its even more of a reason to control the access.

> I mean, crypographically we’ve had solutions to those exact problems for 30 years.

My point exactly - 1password.com addresses those problems (e.g. by adding a random key to the master password, and via Secure Remote Password auth), while using just a master password (sans random key) in a dumbly file-hosted vault does not.

When you talk about “master key”, are you aware about multi-key cryptography?

me and my friend can have private keys to a ”vault” (or, file) that are solely our keys, even if they decrypt the same secret.

No need for a “master password” to unseal the vault.

Here is the gpg docs for it: https://www.gnupg.org/gph/en/manual.html#AEN111

section 5.1 of RFC 2440 explains how it works: https://www.ietf.org/rfc/rfc2440.txt

If I got you right, then 1P does use this mechanism, and LP most likely too. The problem is - how do you store the private keys in a way that their loss is not catastrophic? Services like 1P and LP answer that question, with varying levels of sophistication.

With 1P, it works roughly like this:

- Every vault item is encrypted with the vault’s key (randomly generated number w/ 256 bit, AES)

- For every user that has access to the vault, the user‘s public key is used to encrypt the vault key. I think this is what you meant by multi-key? Adding a team member to a vault means encrypting the vault key with the member‘s public key.

- The user‘s private key in turn is encrypted with the „Account unlock key“, which is made up of: Master password + random secret [1] + salt. Neither of those is ever sent to the servers in plaintext, made possible by zero knowledge proofs.

If you stored your ciphertext on a dumb file hoster: Sure you can increase entropy in the master password to match 1P‘s random secret. Or you can use a 256bit key as master password. But where do you store that safely? The macOS/iOS secure enclave would be appropriate, and that’s what 1P is doing. Otherwise, that key would have to be encrypted again, right, in order to allow secure backup? Aren’t we entering recursion there? At some point you need to have either a password you can commit to memory, or one that’s stored in sthg like a secure enclave.

You can also use a high entropy password and print it out, like 1P is suggesting for the secret key. But exposure of the printed secret key in the case of 1P doesn’t mean a breach because it’s just a salt in addition to the master password.

1: Random secret is stored on your device, and they ask you to print it out upon signup. It’s never shared in plaintext with the 1P server, same as the master password.

Vaults stored in Dropbox could be brute forced if an attacker ever gains access to the ciphertext. The 1P service mitigates this by adding a random key as salt that’s stored locally (iOS keychain/browser storage). That key never leaves your device (authentication is done via zero knowledge proof), so the master password is virtually impossible to brute force right now, even with a very weak master password.

I can highly recommend reading the white paper, it’s very well written and kinda like a comprehensive guide to E2EE which every SWE should be familiar with anyway.

And what do you mean by Apple being lethargic? They added a secure enclave to all their devices that is probably the most secure storage and crypto processor you can hope to get for that kind of money. They also added the option of completely end to end encrypted backups. Because of the secure enclave, that’s actually a really safe option.

> Vaults stored in Dropbox could be brute forced if an attacker ever gains access to the ciphertext.

I’m sorry, but could you expand on this? If I leave my encrypted password vault on Dropbox’s servers, then of course they could attempt to brute force it. I thought the entire point of the encrypted vaults is that brute forcing is computationally infeasible, but technically possible.