Thanks for reading! I hope you’ve enjoyed this deep dive into how 1Password works.
We’ve covered a lot:
- Why I even went down this path
- Unlocking macOS clients and the 2SKD process
- Unlocking Windows clients
- Decrypting data in the cloud-based vault system
- Unlocking and decrypting local vaults
But there’s actually quite a bit I haven’t touched upon.
One thing I totally skipped over was the strength of the master password. There are actually several different password derivation steps in use by 1Password, all using PBKDF2:
- Two Secret Key Derivation (2SKD) for MUK and SRP – uses 100,000 iterations
- Encrypted Master Key decryption (Windows Clients) – variable number of iterations, adjusted to take about 1 second total
- Local vaults – 100,000 iterations
- Export key (unfinished feature, see below) – 500,000 iterations
1Password doesn’t specifically enforce a password complexity requirement, but they generally suggest a four-word phrase, taken from a dictionary of about 18 thousand words (it’s actually 18,328). This works out to about 56 bits of entropy, or equivalent to a 9-character password of upper case, lowercase, numbers, and symbols (a 96-letter alphabet).
In May 2018, AgileBits sponsored a password cracking competition to see if this was strong enough. But to make it actually winnable, they dropped their challenge to only 3 words (42 bits, or about a 6-7 character password). For the purpose of the challenge, they focused only on the 100,000 rounds of PBKDF2 – the rest of the 2SKD process doesn’t affect overall password cracking speed.
As I write this, six months after the challenge opened, only one of the 5 challenge hashes has been cracked (in mid October). (It was “mansard humpback unbutton”, if you’re curious). If one accepts that moving from 3 words to 4 will multiply the required time by 18,000 (the length of the word list), then this certainly makes it look like their recommended strength is sufficient. (UPDATE: On November 7, another password (“faint bust perturb”) was cracked by the same team as the first). I’ll let AgileBits process the winners’ reports and analyze what it means for their recommendations, but my guess is that the four-word suggestion is pretty solid.
Other Features and Clients
New Exports Feature When writing this up, I ran across some new data fields that I didn’t understand, and dug a bit. I didn’t get too far, so I asked on the forums, and it turns out, this is for a not-yet-completed feature. Basically, they’re storing another decryption key, based solely on the user’s Master Password (and 500,000 PBKDF2 iterations). This key then decrypts new exported copies of all the data. If you change your password, then the old key is encrypted using the key derived from your new password, but the existing exports are left untouched (so they can still be decrypted with the old key). The idea here is to automatically keep an encrypted local export that you can easily recover with just your password, while not bogging down the actual day-to-day use of the application. This (the last I saw) was not yet finished, and so things may certainly change.
Browsers You can also access 1Password through a browser. When you do that, your Secret Key is stored in the browser’s local storage, encrypted by a key derived (through SHA-1) from the phrase “Obfuscation Does Not Provide Security But It Doesn’t Hurt”. So this may, on a shared computer, put your Secret Key at risk – I recommend sticking with the native clients and not using the browser except to manage the cloud-based features of the system. And when you that, be sure to indicate that you’re on a “public computer” so this data doesn’t get cached. There’s also a more full-featured web-based client called 1PasswordX, which I really haven’t looked into at all.
Command Line Interface AgileBits have released a command-line interface, which is really powerful, and also really hard to use.
Mobile Clients I haven’t looked at the iOS client in a while (I haven’t been keeping up with jailbroken devices), and I’ve never looked at the Android version.
1Password Mini and Browser Extensions There’s a whole host of different security issues related to how the browser extension interacts with 1Password, which have been publicly explored in detail by Agilebits.
Sharing via Text Message You can send passwords via text message, but that’s not super secure. Though the data is encrypted, the password is (I believe) fixed for all applications and could be extracted by an attacker. So really, it’s just obfuscated. I haven’t been able to look into that yet.
Other Local Storage On the Mac, there’s some additional data stored in preferences files, which is encrypted / obfuscated by the client. I haven’t dug too deeply into those structures, but they didn’t look like anything super-sensitive (that is, didn’t directly factor into the security of vaults, etc.).
Touch ID Beginning with 1Password 6, Macs with Touch ID could use that to unlock the client. A version of the enc_login data was stored in the system LocalItems keychain (which gets synced as the iCloud Keychain if that’s enabled). This data was encrypted using a random AES+HMAC key (64 bytes total), and that key was base-64 encoded and stored in the 1Password user preferences file.
Security came from the system refusing to provide the keychain data to the end user on the system, unless they were the 1Password client (proven using Mac Application Signing features). That would be released only when the user authenticated using the Touch ID feature, and then decrypted using the key pulled from Preferences.
This wasn’t quite foolproof, however, as it was possible to retrieve this keychain data from another Mac, if the keychain was synchronized over iCloud.
In 1Password version 7, however, this has all been changed. Now the data is stored in the preferences file, but it’s encrypted using a key that resides in the local Mac’s Secure Enclave. That key is never released to the user (in any form) but is avaialble to decrypt data which is sent to it. So the user authenticates with Touch ID, sends the encrypted data from the preferences file, and the secure enclave decrypts the login data and returns it to the client.
I’m sure I’m missing more. As I said back in the beginning, I’m not even looking at the networking aspect of the system, which involves a 1Password-specific encryption layer atop existing TLS encryption, and Secure Remote Passwords. There are also other application-level features I haven’t discussed – 2FA, WatchTower, and others.
And there’s also all the cloud-based features: Account recovery (so your team admin can restore your vaults if you forget your password or key), adding and removing team members from vaults, travel mode, and more.
Pulling it All Together
Just for fun, here’s a diagram I include in my talk that kind of pulls it all together. It’s certainly of no value whatsoever in a crowded auditorium, but it does show you everything at once, and so may be a useful reference.
(note that this doesn’t include what happens when you have local vaults enabled – let’s not get too crazy)
Thanks for reading!
I hope I’ve at least helped to understand how the most important bits work in 1Password:
- How you unlock the 1Password client
- How data is encrypted (and vaults arranged) for cloud accounts
- How local account data is encrypted
Ultimately, my goal has been to clarify the information provided by AgileBits – fill in some of the missing details, resolve ambiguities, etc. And finally, to prove that it really does work the way they say.
I have always felt that it’s important that we understand how the technology we rely upon works, and a password manager is a VERY IMPORTANT piece of technology. So hopefully, this (plus the example data and scripts I’ve provided) will give you the understanding to be confident in how 1Password works, so you can make your own informed risk decisions about the system.
Thanks so much for slogging through all this. In case you missed them earlier, here are links to various resources I’ve referred to in the series: