2 Principles
1Password by AgileBits provides powerful administration of 1Password data (login credentials, for example). This document describes how this happens securely.
The same approach to security that has driven the design of 1Password prior to offering 1Password accounts went into the current design. The first one being we can best protect your secrets by not knowing them.
Principle 1: Privacy by design
It’s impossible to lose, use, or abuse data one doesn’t possess. Therefore we design systems to reduce the amount of sensitive user data we have or can acquire.
You’ll find Principle 1 exemplified throughout our system, from our inability to acquire your account password during authentication through our use of Secure Remote Password (SRP) to our use of two-secret key derivation (2SKD) which ensures we aren’t in a position to even attempt to crack your account password. Likewise, our use of end-to-end encryption protects you and your data from us and anyone who may gain access to our servers.
Our second principle follows directly from the first.
Principle 2: Trust the math
Mathematics are more trustworthy than people or software. Therefore, when designing a system, prefer security that is enforced by cryptography rather than software or personnel policy.
Cryptography prevents one person from seeing the items they’re not entitled to see. Even if an attacker were able to trick our servers (or people) into misbehaving, the mathematics of cryptography would prevent most attacks. Throughout this document, assume all access control mechanisms are enforced through cryptography unless explicitly stated otherwise.
We also strive to bring the best security architectures to people who are not security experts. This is more than just building a product and system that people want to use, it’s part of the security design itself.
Principle 3: People are part of the system
If the security of a system depends on people’s behavior, the system must be designed with an understanding of how people behave.
If people are asked to do something that isn’t humanly possible, they won’t do it. Principle 3 is obvious once it’s stated, but sadly it has often been overlooked in the design of security systems. For example, not everyone wants to become a security expert or read this document, but everyone is entitled to security whether or not they seek to understand how it works.
The underlying mechanisms for even seemingly simple tasks and functions of 1Password are often enormously complex. Yet according to Principle 3, we don’t wish to confront people with that complexity. Instead, we choose to simplify things so people can focus on accomplishing the task at hand.
Concealing the necessary complexity of the design from users when they just want to get things done is all well and good, but we should never conceal the security design from security experts, system and security administrators, or curious users. Thus we strive to be open about how our system works.
Principle 4: Openness
Be open and explicit about the security design of our systems so others may scrutinize our decisions.
A security system should be subject to public scrutiny. If the security of a system were to depend on aspects of the design being kept secret, those aspects would actually be weaknesses. Expert and external scrutiny is vital1 both for the initial design and for improving it as needed. This document is part of our ongoing effort to be open about our security design and implementations.
Part of that openness requires that we acknowledge where we haven’t (yet) been able to fully comply with all of our design principles. For example, we haven’t been able to deny ourselves the knowledge of when you use 1Password in contrast to Principle 1; some finer grained access control features are enforced by server or client policy instead of cryptographically (cf. 2); people still need to put in some effort to learn how to use 1Password properly (cf. 3); and not everything is yet fully documented (cf. 4). We do attempt to be clear about these and other issues as they come up and will collect them in the appendix in “Beware of the Leopard.”
On occations, this document will go into considerable technical detail that may not be of interest to every reader. And so, following the conventions developed in The TEX Book2, some sections will be marked as a dangerous bend. Most of the text should flow reasonably well if you choose to ignore said sections.
Many of those dangerous bend technical discussions involve explaining the rationale for some of the very specific choices we made selecting cryptographic tools and modes of operation. There are excellent cryptographic libraries available, offering strong tools for every developer. But even with the best available tools it’s possible to pick the wrong tool for the specific job or to use it incorrectly. We feel it’s important not just to follow the advice of professional cryptographers, but to have an understanding of where that advice comes from. That is, it’s important to know your tools.
Principle 5: Know your tools
We must understand what security properties a tool has and doesn’t have so we use the correct tool the right way for a particular task.
Throughout this document, there will be a process of elaboration. Descriptions presented in earlier sections will be accurate as far as they go, but may leave some details for greater discussion at some other point. Often details of one mechanism make complete sense only in conjunction with details of another that in turn depend on details of the first. And so, when some mechanism or structure is described at some point, it may not be the last word on that mechanism.