1Password Security Design 1Password Memberships [git] • Branch: main @ adb528d • Release: v0.3.1 (2021-04-19) Head tags: v0.3.1 Key Security Features 1Password offers a number of notable security features, including True end-to-end encryption All cryptographic keys are generated and man- aged by the client on your devices, and all encryption is done locally. Details are in A deeper look at keys. Server ignorance We are never in the position of learning your Master Password or your cryptographic keys. Details are in A modern ap- proach to authentication. Nothing “crackable” is stored Often a server will store the password hash. If captured, this can be used in password cracking attempts. Our two-secret key derivation mixes your locally held Secret Key with your Master Password so that data we store cannot be used in cracking attempts. See Making verifiers uncrackable with 2SKD for details. Thrice encrypted in transport When your already encrypted data travels between your device and our servers, it is encrypted and authenti- cated by Transport Layer Security (TLS) and our own transport en- cryption. Details are in Transport Security. You control sharing Only someone who holds the keys to a vault can share that data with someone else. We do not have those keys, so sharing decisions come from you. See How Vault Items Are Securely Shared for details. Team managed data recovery We do not have the ability to recover your data if you forget your Master Password or lose your Secret Key (since you have end-to-end security). But recovery keys can be shared with team members. Details are in Restoring a User’s Access to a Vault. [git] • Branch: main @ adb528d • Release: v0.3.1 (2021-04-19) Head tags: v0.3.1 Which controls are cryptographically Contents enforced . 33 Server-enforced controls . 34 Which controls are enforced by server policy . 34 Client-enforced policy . 35 Principles 6 Which controls are enforced by client policy . 35 Master Password and Secret Key 9 Multiple layers of enforcement . 35 Master Password ............... 9 Secret Key ................... 10 Administrator Roles and Powers 37 Emergency Kit . 11 Restoring a User’s Access to a Vault 38 A modern approach to authentication 13 Overview of Groups . 38 What we want from authentication . 13 Recovery Groups . 39 Traditional authentication . 14 Implicit sharing . 39 Password Authenticated Key Exchange 14 Protecting vaults from Recovery Group Making verifiers uncrackable with 2SKD 16 members . 39 Recovery risks . 40 How Vault Items Are Secured 17 Key derivation overview . 18 1Password Connect 43 A first look at Key Set . 18 The Connect Server . 44 Flexible, yet firm . 19 Service account . 44 Local deployment . 45 How Vault Items Are Securely Shared 21 Credential store . 45 Getting the message (to the right people) . 21 The credentials file . 45 A deeper look at keys 23 Encrypted credentials . 46 Key creation . 23 Verifier . 46 Key derivation . 24 Interprocess key . 47 Deriving two keys . 24 Bearer token . 47 Preprocessing the Master Password . 24 Header . 47 Preparing the salt . 26 Payload . 48 Slow hashing . 26 Signature . 49 Combining with the Secret Key . 26 How We Secure Data on Clients 50 Deriving the authentication key . 27 Initial sign-up . 27 Transport Security 51 Protecting email invitations . 28 Data at rest ................... 52 Enrolling a new client . 29 TLS ....................... 52 Normal unlock and sign-in . 31 Our transport security . 53 Client delivery . 53 Revoking Access 32 Server Infrastructure 54 Access control enforcement 33 What the server stores . 54 Cryptographically enforced controls . 33 How is your data stored . 56 How are servers deployed and managed . 57 [git] • Branch: main @ adb528d • Release: v0.3.1 (2021-04-19) Head tags: v0.3.1 Appendices 57 Changelog 86 [0.3.1] – 2021-04-19 . 86 A Beware of the Leopard 58 Improved . 86 Crypto over HTTPS . 58 [0.3] – 2021-04-13 . 86 Pinning . 59 Improved . 86 Crypto in the browser . 60 New .................... 86 Recovery Group powers . 60 [0.2.10] – 2019-01-12 . 87 No public key verification . 61 Improved . 87 Limited re-encryption secrecy . 61 [0.2.9] – 2018-12-30 . 87 Revocation . 61 Improved . 87 Your mitigations . 62 [0.2.8] – 2018-12-30 . 87 Master Password changes don’t change key- New .................... 87 sets .................... 62 Improved . 87 Your mitigations . 62 [0.2.7] – 2018-09-10 . 87 Clients handling multiple accounts . 62 New .................... 87 Mitigations . 63 Improved . 87 Policy enforcement mechanisms not always [0.2.6] – 2017-04-11 . 88 clear to user . 63 New .................... 88 Malicious client . 64 Improved . 88 Vulnerability of server data . 64 [0.2.5] - 2017-02-20 . 88 Malicious processes on your devices . 64 Improved . 88 Locally exposed Secret Keys . 64 [0.2.4] - 2016-09-28 . 88 Revealing who is registered . 65 New .................... 88 Use of email . 65 Improved . 89 Fixed ................... 89 B Secure Remote Password 66 [0.2.3] - 2015-11-27 . 89 Registration . 66 New .................... 89 Sign-in ................... 67 Fixed ................... 89 With a strong KDF . 67 [0.2.2] - 2015-11-03 . 89 The math of SRP . 68 New .................... 89 Math background . 68 Diffie-Hellman key exchange . 69 Authenticated key exchange . 70 C Strengthening User Master Passwords 71 Some words about strong Master Passwords 71 Slow hashing . 71 D Securing Documents 72 E Verifying public keys 73 Types of defenses . 74 Trust hierarchy . 74 User-to-user verification . 74 The problem remains . 76 [git] • Branch: main @ adb528d • Release: v0.3.1 (2021-04-19) Head tags: v0.3.1 List of Stories List of Figures 1 A (bad) day in the life of your data . 10 1 Two-secret Key Derivation . 9 2 A day in the life of an Emergency Kit . 11 2 Master Password ............ 9 3 A day in the life of an item being created 19 3 Secret Key . 10 4 Days in the life of an algorithm upgrade 19 4 Sample Emergency Kit . 11 5 A day in the life of a shared vault . 21 5 Encourage saving Emergency Kit . 12 6 A week in the life of revocation . 32 6 Very traditional authentication . 14 7 A day in the life of read-only data . 34 7 Authentication security properties . 15 8 A day in the life of a concealed password 36 8 Algorithm for creating and populating a 9 Mr. Talk is not a good team player . 61 vault .................... 17 10 A weak primary Master Password un- 9 Structure of a How collections of locks a stronger account . 63 keys and their metadata are organized 11 Mr. Talk is the cat in the middle . 73 within 1Password for Teams . 18 10 Master Unlock Key derivation . 25 11 Sample Master Unlock Key (MUK) . 26 12 Example add link . 29 13 First auth response . 29 List of Asides 14 Personal key set overview . 30 15 Encrypted symmetric key . 30 1 Non-ASCII passwords . 25 16 Public key details . 30 17 Vault recovery . 41 18 Connect server in the middle . 43 19 Connect credentials JSON . 45 20 encCredentials object . 46 List of Tables 21 Decrypted credential structure . 46 1 Authentication schemes . 16 22 Connect server verifier . 46 2 Random number generators . 23 23 Connect server IPC key . 47 3 Symbols . 28 24 JWT header . 47 4 Transport protections . 52 25 JWT payload . 48 B.1 SRP simple KDF . 67 B.2 Sophie Germain . 69 B.3 Diffie-Hellman key exchange . 70 [git] • Branch: main @ adb528d • Release: v0.3.1 (2021-04-19) Head tags: v0.3.1 Principles 1Password by AgileBits provides powerful administration of 1Password data (login credentials, for example) for teams of individuals. This doc- ument describes how this is done securely. The same approach to security that has driven the design of 1Pass- word prior to offering 1Password accounts has gone into the current design. The first one is that we can best protect your secrets bynot knowing them. Privacy by Design It is impossible to lose, use, or abuse data PRINCIPLE 1 Privacy by Design one doesn’t possess. Therefore we design systems to reduce the amount of sensitive user data we have or can acquire. You will find Principle 1 exemplified throughout our system, from our inability to acquire your Master Password during authentication (through use of Secure Remote Password (SRP) to our use of two-secret key deriva- tion (2SKD) which means that we aren’t in a position to even attempt to crack your Master Password. Likewise, our use of end-to-end encryp- tion protects you and your data from us or someone who gains access to our servers. Our Principle 2 follows directly from the first: Trust the Math Mathematics is more trustworthy than people PRINCIPLE 2 Trust the Math or software. Therefore, when designing a system, prefer security that is enforced by cryptography instead of enforced by software or personnel policy. It is cryptography that prevents one person from seeing the items that they are not entitled to see. Even if an attacker were able to trick our servers (or people) into misbehaving, the mathematics of cryptog- raphy would prevent most attacks. Throughout this document, assume that 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 themselves security experts. This is more than just building a product and system that people will want to use, it is part of the security design itself: [git] • Branch: main @ adb528d • Release: v0.3.1 (2021-04-19) Head tags: v0.3.1 1PASSWORD SECURITY DESIGN 7 People are part of the system If the security of a system de- PRINCIPLE 3 People are part of the system pends on people’s behavior, the system must be designed with an understanding of how people behave.