I've been very reluctant to use their cloud solution as I trust Dropbox more for security. So I still fight 1password to keep the vault stored in Dropbox.
I figure there are maybe 4 organizations who are active enough to prevent a full download of all their user's data. Google, Dropbox, Amazon, and Facebook. (Maybe Apple, but they seem lethargic.)
Because they store all the passwords to all of our services they are a huge target.
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.
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.
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.
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.
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.
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
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 just store your private key directly, as I think you suggested. But this is not memorable, so where do you back this key up in case your hard drive fails? Aren’t we entering recursion at this point, requiring yet another round of encryption? There’s no end to this. 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 could also print out the private key, like 1P is suggesting for its secret key. But exposure of the piece of paper is a total breach if it’s your private key, but not with 1P‘s secret key.
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.