3 ms·

Not really. Your data would be safe even with 6 character master password (which will not be allowed by 1Password). The random Secret Key provides the addition

Not really. Your data would be safe even with 6 character master password (which will not be allowed by 1Password). The random Secret Key provides the additional protection against brute forcing accounts even when the master password is weak.

eterm 9y ago
Correct me if I'm wrong, but the random secret key must be synchronised somehow, surely? I'm talking about in the case that someone gains access to all your synchronised data.
- latexr 9y ago
  The process of encrypting a password is one-way, meaning that given an encrypted password you can’t run a process to get the original. For an attacker to guess your password, they need to run a bunch of guesses through the same encryption process, and only when they get the same encrypted result they’ll know they have the correct unencrypted one. This is time consuming, so attackers may use rainbow tables[1] — essentially a list with a ton of precomputed passwords they can check. To counteract this you salt[2] a password, essentially adding random data to it. So now even if we have the same password, since our salt (random data) will be different, the resulting encrypted version will also be different. Even if the attacker gets your vault and secret key, they’ll still need to brute-force[3] the password. Ars Technica’s has an excellent explanation of all this[4]. [1]: https://en.wikipedia.org/wiki/Rainbow_table https://en.wikipedia.org/wiki/Rainbow_table [2]: https://en.wikipedia.org/wiki/Salt_(cryptography) https://en.wikipedia.org/wiki/Salt_(cryptography) [3]: https://en.wikipedia.org/wiki/Brute-force_attack https://en.wikipedia.org/wiki/Brute-force_attack [4]: https://arstechnica.com/information-technology/2013/05/how-crackers-make-minced-meat-out-of-your-passwords/ https://arstechnica.com/information-technology/2013/05/how-c...
- AGKyle 9y ago
  The secret key is combined with the master password. See our white paper here: https://1pw.ca/whitepaper https://1pw.ca/whitepaper See Key Derivation on page 24 for this specifically. We call it 2SKD. Page 26 also shows how the secret key and the master password are combined. From that other keys are derived. It's actually a very fascinating process, combined with our use of SRP, I have to say I rather love how well all of this meshes together. In the situation where someone gets your data from our server, which is the big thing people are worried about, they're going to have to combine a guess for your master password and the secret key to perform a guess. They could in theory get your secret key from your local devices, as these are saved there, but your Master Password protects in that case as it's not stored anywhere (unless you've enabled features like Touch ID or Face ID, but those are protected in other ways). Your Secret Key protects your data on our server. It makes brute forcing that data an incredibly expensive process. Your Master Password also helps protect your data on our server, but it also protects your data locally. Let me know if that helps explain things. Kyle AgileBits
  - ADent1 9y ago
    How is the Master Password protected with Touch ID? Seems like it goes in the Apple Keychain, which then Apple wants to sync to iCloud. Can Apple then get my Master Password (along with FBI w/warrant, etc)?
    - gerald766 9y ago
      Apple doesn't sync secure enclave information to iCloud. Also, not all iCloud synced information can be accessed. iCloud Keychain, for example, can not be decrypted by Apple.
    - AGKyle 9y ago
      In 1Password 7 for Mac we generate a key pair in the secure enclave. Then use that key pair to encrypt the Master Password and then save it to the Apple Keychain. All decryption of the Master Password goes through the Secure Enclave. The key pair is generated in, and never leaves, the Secure Enclave. It's how this feature was designed by Apple. Kyle AgileBits

eterm 9y ago

Correct me if I'm wrong, but the random secret key must be synchronised somehow, surely? I'm talking about in the case that someone gains access to all your synchronised data.

latexr 9y ago
The process of encrypting a password is one-way, meaning that given an encrypted password you can’t run a process to get the original. For an attacker to guess your password, they need to run a bunch of guesses through the same encryption process, and only when they get the same encrypted result they’ll know they have the correct unencrypted one. This is time consuming, so attackers may use rainbow tables[1] — essentially a list with a ton of precomputed passwords they can check. To counteract this you salt[2] a password, essentially adding random data to it. So now even if we have the same password, since our salt (random data) will be different, the resulting encrypted version will also be different. Even if the attacker gets your vault and secret key, they’ll still need to brute-force[3] the password. Ars Technica’s has an excellent explanation of all this[4]. [1]: https://en.wikipedia.org/wiki/Rainbow_table https://en.wikipedia.org/wiki/Rainbow_table [2]: https://en.wikipedia.org/wiki/Salt_(cryptography) https://en.wikipedia.org/wiki/Salt_(cryptography) [3]: https://en.wikipedia.org/wiki/Brute-force_attack https://en.wikipedia.org/wiki/Brute-force_attack [4]: https://arstechnica.com/information-technology/2013/05/how-crackers-make-minced-meat-out-of-your-passwords/ https://arstechnica.com/information-technology/2013/05/how-c...
AGKyle 9y ago
The secret key is combined with the master password. See our white paper here: https://1pw.ca/whitepaper https://1pw.ca/whitepaper See Key Derivation on page 24 for this specifically. We call it 2SKD. Page 26 also shows how the secret key and the master password are combined. From that other keys are derived. It's actually a very fascinating process, combined with our use of SRP, I have to say I rather love how well all of this meshes together. In the situation where someone gets your data from our server, which is the big thing people are worried about, they're going to have to combine a guess for your master password and the secret key to perform a guess. They could in theory get your secret key from your local devices, as these are saved there, but your Master Password protects in that case as it's not stored anywhere (unless you've enabled features like Touch ID or Face ID, but those are protected in other ways). Your Secret Key protects your data on our server. It makes brute forcing that data an incredibly expensive process. Your Master Password also helps protect your data on our server, but it also protects your data locally. Let me know if that helps explain things. Kyle AgileBits
- ADent1 9y ago
  How is the Master Password protected with Touch ID? Seems like it goes in the Apple Keychain, which then Apple wants to sync to iCloud. Can Apple then get my Master Password (along with FBI w/warrant, etc)?
  - gerald766 9y ago
    Apple doesn't sync secure enclave information to iCloud. Also, not all iCloud synced information can be accessed. iCloud Keychain, for example, can not be decrypted by Apple.
  - AGKyle 9y ago
    In 1Password 7 for Mac we generate a key pair in the secure enclave. Then use that key pair to encrypt the Master Password and then save it to the Apple Keychain. All decryption of the Master Password goes through the Secure Enclave. The key pair is generated in, and never leaves, the Secure Enclave. It's how this feature was designed by Apple. Kyle AgileBits