The architectural reason 1Password can't read your vault data

There’s a question we get asked constantly, and it’s the right one to ask: “Can 1Password see the contents of my vault?” The answer is no, and it’s because of how we built the product, not just a promise we’re making. That’s an important distinction, because “we promise” has never been an acceptable answer in this industry. After all, promises get broken, and companies get compromised, acquired, and are under constant attack from threat actors. 1Password’s commitment to our security principles is genuine, but what matters more is how we’ve built that commitment into our product and architecture, and the transparency we back it up with with our security white paper. So here’s the precise answer: The way 1Password is built means that we are incapable, on a technical level, of decrypting and reading your vault contents. We're not policy-prevented or contractually restricted; we are technically incapable. This post explains what that means, why we built it this way, and what the real tradeoffs are. Your data is encrypted before it ever leaves your device When you save a password, a credit card number, or a note in 1Password, the first thing that happens is encryption, and it happens on your device, before any data moves anywhere. Encryption here doesn’t mean we “hide” or “scramble” your data and promise not to look. It means your plaintext vault item is transformed into ciphertext using cryptographic keys that are only available on your devices. Without these keys, 1Password is unable to decrypt and read your data. The two keys in question are your 128 bit Secret Key (a 34-character value separated by dashes) and your account password. Together, these produce the cryptographic key that locks and unlocks your vault. Here’s the critical part: neither your Secret Key nor your account password is ever transmitted to 1Password or stored on our servers. We never possess the keys needed to decrypt your vaults. When you set up your 1Password account on a new device, you’re not “downloading” your key from us, you’re entering it yourself (either manually or using a QR code), and your device uses it locally to decrypt the vault data it receives. What we store on our servers is the encrypted version of your vault contents: ciphertext that is, for all practical purposes, indistinguishable from random data without the key to decrypt it. If our servers were compromised tomorrow and an attacker exfiltrated every byte of stored data, they’d only have encrypted blobs they cannot read. Your vault content are encrypted on your device. What reaches our servers is unreadable ciphertext. Even the fastest supercomputer would take (literally) billions of billions of years to try and guess a 128-bit encryption key. That’s what we mean when we say 1Password’s security isn’t built on promises; it’s built on math. What “zero-knowledge” actually means and what it costs The design pattern described above is called zero-knowledge architecture. It means the service provider, in this case, 1Password, has zero knowledge of the plaintext contents of what it’s storing. Zero-knowledge is a meaningful claim because it is an immutable fact of our architecture. But zero-knowledge is a security guarantee with real product implications and intentional constraints. The most significant tradeoff is account recovery. If you forget your account password or lose your Secret Key, we cannot return them to you, because we don’t have them. (If you forget your password, you can regain access to your account by generating a recovery code, but this still requires you to have access to the email account you used to create the account.) The same constraint shapes what features we can build. Any capability that would require 1Password to see your plaintext data is, by design, off the table. We can’t offer server-side search across your vault contents. When we scan your saved passwords and tell you which ones have appeared in a breach, we do that computation on your device and only a partial hash of your password is checked against breach databases, so we learn nothing about the actual credential. Some things that would be convenient to build are simply incompatible with the architecture, and we think that’s the correct tradeoff. The decryption key lives on your device. Encrypted data syncs to our servers, but the key never does. Zero-knowledge also means we can’t be compelled to hand over vault contents we don’t have. A court order can require us to produce data, but it can’t require us to produce a decryption key that doesn’t exist on our systems. (You can read our full policy on legal requests here.) When computation has to happen in the cloud The zero-knowledge constraint of only processing unencrypted data on a user's device works well for storing and syncing data. But some features, particularly enterprise capabilities like company-wide security reporting, require server-side computation. So our question in building those features has been: how can we do t

Excerpt shown under the publisher's RSS terms · 127 words · full text and figures are on the publisher's site