4 ms·

Which people? 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

by joshe 4y ago

Which people? 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.

irrational 4y ago
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.
soraminazuki 4y ago
You trust Dropbox? The company that infamously invited to their board a former government official responsible for authorizing warrantless mass surveillance?
dijit 4y ago
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.
- manmal 4y ago
  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?
  - dijit 4y ago
    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.
    - manmal 4y ago
      > 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.
      - dijit 4y ago
        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 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 https://www.ietf.org/rfc/rfc2440.txt
        manmal 4y ago
        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 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.
manmal 4y ago
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.
- 0cf8612b2e1e 4y ago
  > 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.

by joshe 4y ago

irrational 4y ago

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.

soraminazuki 4y ago

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

dijit 4y ago

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.

manmal 4y ago
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?
- dijit 4y ago
  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.
  - manmal 4y ago
    > 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.
    - dijit 4y ago
      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 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 https://www.ietf.org/rfc/rfc2440.txt
      - manmal 4y ago
        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 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.

manmal 4y ago

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.

0cf8612b2e1e 4y ago
> 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.