A Appendix A: Beware of the leopard
“You hadn’t exactly gone out of your way to call attention to them had you? I mean like actually telling anyone or anything.”
“But the plans were on display…”
“On display? I eventually had to go down to the cellar to find them.”
“That’s the display department.”
“With a torch.”
“Ah, well the lights had probably gone.”
“So had the stairs.”
“But look you found the notice didn’t you?”
“Yes,” said Arthur, “yes, I did. It was on display in the bottom of a locked filing cabinet stuck in a disused lavatory with a sign on the door saying Beware of the leopard.”34
This chapter discusses places where the actual security properties of 1Password may not meet user expectations.
A.1 Crypto over HTTPS
1Password offers a web client which provides the same end-to-end (E2E)Data is only encrypted or decrypted locally on the users’ devices with keys that only the end users possess. This protects the data confidentiality and integrity from compromises during transport or remote storage. encryption as when using the native clients. The web client is fetched from our servers as a set of JavaScript files (compiled from TypeScript source) that’s run and executed locally in the user’s browser on their own machine. Although it may appear to users of the web client that our server has the capacity to decrypt user data, all encryption occurs on the user’s machine using keys derived from their account passwordSomething you must remember and type when unlocking 1Password. It’s never transmitted from your devices. Previously known as Master Password. and Secret KeyA randomly generated user secret key that is created upon first signup. It’s created and stored locally. Along with the user’s account password, it’s required both for decrypting data and for authenticating to the server. The Secret Key prevents an attacker who has acquired remotely stored data from attempting to guess a user’s account password. Previously known as the Account Key.. Likewise authentication in the web-client involves the same zero-knowledge authentication scheme described in 4.
Despite that preservation of end-to-end (E2E)Data is only encrypted or decrypted locally on the users’ devices with keys that only the end users possess. This protects the data confidentiality and integrity from compromises during transport or remote storage. encryption and zero-knowledge authentication, the use and availability of the web client introduces a number of significant risks.
The authenticity and integrity of the web client depends on the integrity of the TLS connection by which it’s delivered. An attacker capable of tampering with the traffic that delivers the web client could deliver a malicious client to the user.
The authenticity and integrity of the web client depends on the security of the host from which it’s delivered. An attacker capable of changing the web client on the server could deliver a malicious client to the user.
The web client runs in a very hostile environment: the web browser. Some attacks on the browser (like a malicious extension) may be able to capture user secrets. This is discussed further in A.1.1.
Without the web-client users would only enter their account passwordSomething you must remember and type when unlocking 1Password. It’s never transmitted from your devices. Previously known as Master Password. into native clients and so would be less vulnerable to phishing attacks.
The web client creates the false impression for many users that encryption is not end-to-end. Although this may not have direct security consequences for the user, it may re-enforce unfortunately low expectations of security in general.
User mitigations include:
- Use (code signed) native clients as much as possible.
- Keep browser software up to date
- Create a specific browser profile for using the web-client
- Pay close attention to browser security warnings
- Use only on trusted networks.
- Manually check certificates
Our mitigations include:
- Use the most recent TLSThe successor to SSL. It puts the “S” in HTTPS. version
- Don’t support weak cipher suites (so avoiding many downgrade attacks)
- Use of safe JavaScript constructions.
- Use HSTSStrict Transport Security has the server instruct the client that insecure HTTP is never to be used when talking to the server. (so avoiding HTTPS to HTTP downgrade attacks)
- Pin Certificates (not yet implemented)
Always be sure to heed all browser warnings regarding TLS connections.
A.1.1 Crypto in the browser
Running security tools within a browser environment brings its own perils, irrespective of whether it’s delivered over the web. These perils include:
The browser itself is a hostile environment, running processes and content that are neither under your control nor ours. Sandboxing within the browser provides the first line of defense. Structuring our in-browser code to expose only what needs to be exposed is another. Over the past decade, browsers have made enormous improvements in their security and in their isolation of processes, but it still remains a tough environment.
JavaScript, the language used within the browser, offers us very limited ability to clear data from memory. Secrets we’d like the client to forget may remain in memory longer than useful.
We have a strictly limited ability to use security features of the operating system when operating within the browser. See section A.10.2 for how this limits the tools available for protecting the Secret KeyA randomly generated user secret key that is created upon first signup. It’s created and stored locally. Along with the user’s account password, it’s required both for decrypting data and for authenticating to the server. The Secret Key prevents an attacker who has acquired remotely stored data from attempting to guess a user’s account password. Previously known as the Account Key. when stored locally.
There’s a paucity of efficient cryptographic functions available to run in JavaScript. As a consequence, the WebCrypto facilities available in the browsers we support impose a limit on the cryptographic methods we can use. For example, our reliance on PBKDF2 instead of a memory-hard KDF such as Argon2 is a consequence of this.
A.2 Recovery Group powers
From a cryptographic point of view, the members of a Recovery GroupThe 1Password Group that has a copy of the vault keys for vaults that may need to be recovered if account passwords or Secret Keys are lost. have access to all the vault keys in that group.35 Server policy restricts what a member of the Recovery Group can do with that access, but if a Recovery Group memberA member of a Recovery Group. See Recovery Group is able to defeat or evade server policy and gain access to an encrypted vault (for example, as cached on someone else’s device) then that Recovery Group member can decrypt the contents of that vault.
Depending on the nature of the threat to the team’s data and resources an attacker will put into acquiring it, members of the Recovery GroupThe 1Password Group that has a copy of the vault keys for vaults that may need to be recovered if account passwords or Secret Keys are lost. and their computers may be subject to targeted attacks.
Members of the recovery groupThe 1Password Group that has a copy of the vault keys for vaults that may need to be recovered if account passwords or Secret Keys are lost. must be selected with care and keep their systems secure.
A.3 No public key verification
At present there’s no practical method36 for a user to verify the public key they’re encrypting data to belongs to their intended recipient. As a consequence it would be possible for a malicious or compromised 1Password server to provide dishonest public keys to the user, and run a successful Man in the Middle (MITM)A Man in the Middle attack has Alice believing she’s encrypting data to Bob, while she’s actually encrypting her data to a malicious actor who then re-encrypts the data to Bob. The typical defense for such an attack is for Alice and Bob to manually verify they’re using the correct public keys for each other. The other approach is to rely on a trusted third party who independently verifies and signs Bob’s public key. attack. Under such an attack, it would be possible for the 1Password server to acquire vault encryption keys with little ability for users to detect or prevent it
This is discussed in greater detail in “Appendix C.”
A.4 Limited re-encryption secrecy
A.4.1 Revocation
Removing someone from a vault, group, or team isn’t cryptographically enforced. Cryptographic keys are not changed.
A member of a vault has access to the vault key, as a copy of the vault key is encrypted with that member’s public key. When someone is removed from a vault, that copy of the vault key is removed from the server, and the server will no longer allow that member to get a copy of the vault data.
If prior to being removed from a vault the person makes a copy of the vault key which they store locally, they will be able to decrypt all future data if they find a way to obtain the encrypted vault data. This is illustrated in Story 10. Note this requires the attacker both plan ahead and somehow acquire updated data.
[Monday] Patty (a dog and Team administrator) adds Mr. Talk (neighbor’s cat) to the Squirrel Watchers vault. Molly (another dog) is already a member.
[Tuesday] Mr. Talk makes a copy of all of his keys and stores that copy separately from 1Password.
[Wednesday] Mr. Talk is discovered stealing Patty’s toys and is expelled from the vault (and from the team).
[Thursday] Patty updates the Squirrel Watchers vault with the new hiding place for her toys.
[Friday] Mr. Talk manages to steal a cached copy of the encrypted vault from Molly’s poorly secured device. (Molly still hasn’t learned the importance of using a device passcode on her phone.)
[Saturday] Mr. Talk decrypts the data he stole on Friday using the keys he saved on Tuesday, and is able to see the hiding place Patty added on Thursday.
To launch the attack, Mr. Talk needed to acquire a copy of the encrypted data the server would no longer provide, and he needed to anticipate being fired.
A.4.2 Your mitigations
If you feel that someone removed from a vault may have a store of their vault keys and will somehow be able to acquire new encrypted vault data despite being denied access by server policy, then it’s possible to create a new vault (which will have a new key), and move items from the old vault to the new one. Someone revoked from a vault won’t be able to decrypt the data in the new vault no matter what encrypted data they gain access to.
A.5 Account password changes don’t change keysets
A change of account passwordSomething you must remember and type when unlocking 1Password. It’s never transmitted from your devices. Previously known as Master Password. or Secret KeyA randomly generated user secret key that is created upon first signup. It’s created and stored locally. Along with the user’s account password, it’s required both for decrypting data and for authenticating to the server. The Secret Key prevents an attacker who has acquired remotely stored data from attempting to guess a user’s account password. Previously known as the Account Key. does not create a new personal keyset, it only changes the Account Unlock Key (AUK)Key used to decrypt a user’s personal key set. It’s derived from the user’s account password and Secret Key. Previously known as the Master Unlock Key. with which the personal key setHow collections of keys and their metadata are organized within 1Password. is encrypted. Thus an attacker who gains access to a victim’s old personal key set can decrypt it with an old account password and old Secret Key, and use that to decrypt data that was created by the victim after the change of the account password.
A.6 Local client account password has control of other account passwords
Most 1Password client applications can handle multiple 1Password user accounts. It’s common, perhaps even typical, for an individual to have a 1Password membership as part of the business or organization they’re a member of, as well as being a member of their own 1Password family.
Most 1Password clients are designed to unlock all accounts when unlocked. The account that will locally contain the encrypted secrets to unlock the others is called the primary accountA local client may distinguish a single account it knows about as the primary account. Unlocking this account may automatically unlock secondary accounts the client may handle. See also secondary account. It’s (for most clients) the first account the client signed into. The precise details of how this is handled can vary from client to client, but in essence, the secrets needed to unlock a secondary account (the AUKKey used to decrypt a user’s personal key set. It’s derived from the user’s account password and Secret Key. Previously known as the Master Unlock Key. and SRP-\(x\)The client secret, 𝑥, used by the Secure Remote Password (SRP) protocol. Derived from the user’s account password and Secret Key.) are encrypted with (keys encrypted by) the AUK of the primary account.
The security risk is that account password policies that may be set and expected by an organization won’t be followed in practice if the account with such policies is a secondary accountAn account that a client may unlocked automatically when the primary account is unlocked. See also primary account for a particular client.
Molly (a dog) is a member of a business account for Rabbit Chasers Inc., and Patty, an administrator for Rabbit Chasers Inc., has used the features of a business account to set very strict account password requirements for all of its members. So Molly’s account password for that account does conform to that account’s requirements. Patty is naturally under the impression that Molly must use the strong account password when unlocking her work account.
But Molly is also a member of a family account, and in her family account she has set her password to be squirrelrabbit, which is easily guessable by anyone familiar with Molly. Furthermore, Molly set up her family account first when she set up 1Password on her device. She added her work account later.
When she first added her work account to that device, she had to enter the strong account password for that account, but every time she unlocks 1Password thereafter, she unlocks both accounts with squirrelrabbit.
One day the evil neighborhood cat, Mr. Talk, steals Molly’s device. Mr. Talk can guess Molly’s weak family account account password, and unlocking 1Password on Molly’s computer can now unlock Molly’s work account as well.
Patty is not amused.
An additional problem with this scheme is that users are more likely to forget they have a separate account password for their secondary account(s), and are more likely to forget those passwords.
A.7 Policy enforcement mechanisms not always clear to user
Readers of this document may recall from “Access control enforcement” that some controls (such as the ability to decrypt and read the contents of a vault) are enforced through cryptography, while others are enforced only through the client user interface (such as the ability to print the contents of a vault they have use access to). The security properties of those differ enormously. In particular, it’s very easy to evade policy that is only enforced by the client.
Many team administrators will not have read this document or other places where the distinction is documented. Therefore, there’s a potential for them to have an incorrect impression of the security consequences of their decisions.
A.8 Malicious client
There’s no technical barrier to a malicious client, which might generate bad keys or send keys to some third party.
A.9 Vulnerability of server data
It should be assumed that governments, whether through law enforcement demands or other means, may gain access to all the data we have or our data hosting provider has. This may happen with or without our knowledge or consent. The same is true for non-governmental entities which may somehow obtain server data. Your protection is to have a good account passwordSomething you must remember and type when unlocking 1Password. It’s never transmitted from your devices. Previously known as Master Password. and to keep your Secret KeyA randomly generated user secret key that is created upon first signup. It’s created and stored locally. Along with the user’s account password, it’s required both for decrypting data and for authenticating to the server. The Secret Key prevents an attacker who has acquired remotely stored data from attempting to guess a user’s account password. Previously known as the Account Key. secure.
Although we may resist law enforcement requests, we obey the laws of the jurisdictions in which we are obliged to do so.
A.10 Malicious processes on your devices
Malware that can inspect the memory of your computer or device when the 1Password client has unlocked your data will be able to extract secrets from the 1Password process. Malware that can install a malicious version of 1Password and have you execute it will also be able to extract your secrets. After malware running on a system has gained sufficient power, there’s no way in principle to protect other processes running on that system.
But we must also consider the threat posed by less powerful malware, and in particular with respect to the exposure of the Secret KeyA randomly generated user secret key that is created upon first signup. It’s created and stored locally. Along with the user’s account password, it’s required both for decrypting data and for authenticating to the server. The Secret Key prevents an attacker who has acquired remotely stored data from attempting to guess a user’s account password. Previously known as the Account Key..
A.10.1 Malicious or undesired browser components
When you use 1Password in your web browser, browser extensions – even built-in browser features – can expose the data you fill into your browser. This can have explicit malicious intent, like when a browser extension monitors the data input into text fields to spy on you. Sometimes this can be accidental, such as when browser extensions submit the data you put into text fields to perform autocompletion features, perform translation, or store or analyze the text you’re typing in some other way.
The 1Password browser extension tries to avoid filling certain form fields if it suspects data may be submitted elsewhere; however, you should use caution when selecting your web browser and extensions, and attempt to understand if and when they send text you enter other places.
A.10.2 Locally exposed Secret Keys
After a client is enrolled, it will store a copy of the Secret KeyA randomly generated user secret key that is created upon first signup. It’s created and stored locally. Along with the user’s account password, it’s required both for decrypting data and for authenticating to the server. The Secret Key prevents an attacker who has acquired remotely stored data from attempting to guess a user’s account password. Previously known as the Account Key. on the local device. Because the Secret Key must be used to derive the user’s AUKKey used to decrypt a user’s personal key set. It’s derived from the user’s account password and Secret Key. Previously known as the Master Unlock Key. it cannot be encrypted by the same AUK or by any key directly or indirectly encrypted with the AUK. Depending on client and client platform, the Secret Key may37 be stored on the device using some of the protections offered by the operating system and lightly obfuscated. But it should be assumed that an attacker who gains read access to the user’s disk will acquire the Secret Key.
Recall from the discussion of two-secret key derivation (2SKD)Two different secrets, each with their own security properties, are used in deriving encryption and authentication keys. In 1Password, these are your account password (something you know) and your Secret Key (a high-entropy secret you have on your device). in 4.1.3 that the Secret KeyA randomly generated user secret key that is created upon first signup. It’s created and stored locally. Along with the user’s account password, it’s required both for decrypting data and for authenticating to the server. The Secret Key prevents an attacker who has acquired remotely stored data from attempting to guess a user’s account password. Previously known as the Account Key. is designed so an attacker won’t be in a position to launch an offline password-guessing attack if they capture data from our server alone. That is, the Secret Key provides extremely strong protection for users if our servers were to be breached. The Secret Key plays no security role if the user’s system is breached. In the latter situation, the strength of the user’s account passwordSomething you must remember and type when unlocking 1Password. It’s never transmitted from your devices. Previously known as Master Password.38 determines whether an attacker will be able to decrypt data captured from the user’s device.
A.10.3 Device keys used with passkey and single sign-on unlock
A client enrolled using passkeyA credential with which you authenticate to a server. Unlike a password, the passkey isn’t sent to the server to authenticate. Instead, the passkey signs a challenge the server provides to your device. This process is also known as WebAuthn or FIDO2 authentication. or SSOIn the setting of a company or another organization, when you are provided with a single set of username, password, or other authentication factors to log in to services that company or organization provides for you. It’s one of the methods that can be used to sign in to 1Password. unlock (described in “Unlock with a passkey or SSO”) doesn’t store a Secret KeyA randomly generated user secret key that is created upon first signup. It’s created and stored locally. Along with the user’s account password, it’s required both for decrypting data and for authenticating to the server. The Secret Key prevents an attacker who has acquired remotely stored data from attempting to guess a user’s account password. Previously known as the Account Key. locally. Instead it stores a device keyA cryptographic key stored on a 1Password client that uses single sign-on (SSO). It’s used to decrypt the credential bundle it receives from the server upon successful sign in. See SSO locally. The combination of a device key and successful passkey or SSO authentication is required to unlock a 1Password account on those devices.
On iOS, macOS, and Android devices, we protect the device keyA cryptographic key stored on a 1Password client that uses single sign-on (SSO). It’s used to decrypt the credential bundle it receives from the server upon successful sign in. See SSO with the device’s hardware security features; other devices don’t reliably allow protecting an encryption key with hardware, nor do web browsers on any platform. In cases which we can’t store the device key protected by a hardware mechanism, we store it (lightly obfuscated) on the computer’s storage drive. This means malware could read the device key and can use it to attempt to access a user’s 1Password account.
If Oscar runs malware on Alice’s computer when she uses SSOIn the setting of a company or another organization, when you are provided with a single set of username, password, or other authentication factors to log in to services that company or organization provides for you. It’s one of the methods that can be used to sign in to 1Password. to unlock 1Password, he can steal both Alice’s device key and Alice’s SSO session cookies from her browser’s cache. Oscar can use the combination of items to unlock Alice’s 1Password account. Similarly, if Oscar has access to the hard drive contents from Alice’s computer (like when he gains access to a backup of Alice’s computer or performs forensic analysis on her computer) he can copy this information and unlock Alice’s 1Password account, as well.
Devices that unlock with passkeysA credential with which you authenticate to a server. Unlike a password, the passkey isn’t sent to the server to authenticate. Instead, the passkey signs a challenge the server provides to your device. This process is also known as WebAuthn or FIDO2 authentication. store their passkey unlocking information in their operating system’s passkey provider. We rely on the operating system and device manufacturer to prevent malware from being able to steal the authentiction information for passkeys. We don’t use session information stored in the web browser to unlock accounts with passkeys.
Because of the risks of the device key and single sign-on authorization data sitting together on a disk we only offer SSOIn the setting of a company or another organization, when you are provided with a single set of username, password, or other authentication factors to log in to services that company or organization provides for you. It’s one of the methods that can be used to sign in to 1Password. to businesses that can weigh the risks and rewards of using SSO with device security aspects. Businesses using SSO can configure the details of devices used, the single sign-on provider used, and the way single sign-on is used within 1Password to fit their individual security needs.
A.11 Revealing who is registered
If Oscar suspects that alice@company.example is a registered user in a particular Team or Family, it’s possible for him to submit requests to our server that would allow him to confirm an email address is or isn’t a member of a team. Note that this does not provide a mechanism for enumerating registered users, it’s only a mechanism that confirms whether or not a particular user is registered. Oscar must first make his guess and test that guess.
We attempted to prevent this leak of information and believed we had. A design error (that’s difficult to fix) means we must withdraw our claim of that protection.
A.12 Use of email
Both invitations and recovery messages are sent by email. It’s very important that when administrators or Recovery Group membersA member of a Recovery Group. See Recovery Group take actions that result in sensitive email being sent, they check with the recipients through means other than email that the messages were received and acted upon.
1Password Teams accounts also have a permission called “Manage All Groups” with equivalent cryptographic access, which is only given to the Administrators and Owners groups by default.↩︎
An impractical method for the users to run 1Password in a debugger to inspect the crucial values of the public keys themselves. Additionally, the 1Password command line utility (as of version 0.21), has an undocumented method to display public keys and fingerprints of users.↩︎
We’re deliberately vague about this, as practice may change rapidly from version to version, including different behaviors on different operating system versions.↩︎
The slow hashing (described in 8.2.4) in our key derivation function goes some way to increase the work that an attacker must do to verify account password guesses from data captured from the user, but it cannot substitute a strong account password.↩︎