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.