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

[2]: https://en.wikipedia.org/wiki/Salt_(cryptography)

[3]: https://en.wikipedia.org/wiki/Brute-force_attack

[4]: https://arstechnica.com/information-technology/2013/05/how-c...

The secret key is combined with the master password. See our white paper here:

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

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)?

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.

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