11 Access control enforcement
Users (and attackers) of 1Password are limited in what they can do with the data. Enabling the right people to see, create, or manipulate data while preventing the wrong people from doing so is the point of 1Password. The sorts of powers that an individual has are often discussed in terms of Access Control Lists (ACLs). For want of a better term, we’ll use that language here; however, it should be noted that the mechanisms by which these controls are enforced aren’t generally the same as the ones for more traditional ACLs. Indeed, different controls may be enforced by different mechanisms, even if presented to the user in the same way.
Broadly speaking, there are three kinds of control mechanisms. These are cryptographic enforcement of policy, server enforcement of policy, and client enforcement of policy.
11.1 Cryptographically enforced controls
If someone hasn’t been given access to a vault, it’s impossible in all practical terms for them to decrypt its data. So at the simplest level, if a user hasn’t been added to a vault, the mathematics of cryptography ensure they won’t be able to decrypt it.
Because the server never has access to decrypted vault keys, it can’t give out those keys to anyone. Therefore the server simply doesn’t have the power to grant someone access to a vault. Such requirements are cryptographically enforced.
Among the mechanisms cryptographically enforced:
- Unlocking a vault.
- Only those with access to a vault can share it.
- User email address can be changed only by the user.
- Server doesn’t learn user’s 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. or account passwordSomething you must remember and type when unlocking 1Password. It’s never transmitted from your devices. Previously known as Master Password..
11.2 Server-enforced controls
Cryptography doesn’t prevent a user (or their client) with access to the vault key from adding, deleting, or modifying items in that vault when the information resides locally on their device. The same key they use to decrypt the data could be used to encrypt modified data.
But 1Password offers the ability to grant individuals read permission to a vault while denying them write permission. The server will reject any attempt from a read-only user of a vault to upload data to that vault. This, and other features, are enforced by server policy. An example of one of these in action is presented in Story 8.
Patty (a clever and sneaky dog) has been granted access to a vault called “Locations” that contains the locations of the water dish and the dog door. So has another member of the team, Morgan le Chien.
Patty thinks she will have the place to herself if Morgan can’t manage to settle in. So she’d like to give Morgan misleading information. Although Patty has been granted only read access to the Locations vault, she is a remarkably clever dog and extracts the vault key from her own data. The same vault key that decrypts items is also used to encrypt items.
She modifies the location of the water bowl (listing the driest part of the house) and encrypts her modified data with the vault key. Then she tries to send this modified data to the server so Morgan will get that information instead.
But she finds that server policy prevents her from uploading modified data. Although cryptographically she had the ability to modify the data, she could only do so on her system. Her evil plan was foiled by server policy.
Of course, her plan would have failed anyway. Morgan is happy to drink from anything resembling a water receptacle, and can manage remarkably well even if she doesn’t know the location of the water bowl.
11.3 Client-enforced controls
Client-enforced controls are limitations enforced within either the web browser or a native client, such as an iOS application. Because the web browser or native client is running on a user’s system and outside our control, these policies may be circumvented by a malicious client or determined user. This doesn’t reduce their usefulness to ordinary users and may help prevent unintended disclosures or accidental actions.
See Story 9 for an illustration of what client-enforced policies can and can’t do.
11.3.1 Controls enforced by client policy
Each of the client policies requires a server or cryptographically enforced policy be granted in order to be allowed. For example, the Import permission may be circumvented by a client, but the user will be unable to save the newly imported item to the server because the Write permission is enforced by the server, not the client.
Importing items into a vault. A user may still create multiple items manually provided they have permission to create new items in the vault. This permission may be used to restrict how many items a user may easily create or prevent accidentally importing items.
Exporting items from a vault. A user may still obtain the item data by other means and create files that aren’t controlled by 1Password. This permission may be used to prevent accidentally disclosing the contents of an entire vault.
Revealing a password for an item. A user may still obtain the password by examining a web page using the developers’ tools for their web browser. This permission may be used to prevent accidental disclosure and may help reduce the risk of shoulder surfing and other social engineering attacks.
Printing one or more items. A user may still obtain the item data by other means; create files that are not controlled by 1Password and print out those files. This permission may be used to prevent accidentally disclosing the contents of an entire vault.
11.4 Multiple layers of enforcement
Something enforced by cryptography may also be enforced by the server, and something enforced by the server may also be enforced by the client. For example, the server won’t provide the vault data to non-members of a vault, even though non-members wouldn’t be able to decrypt the data even if it were provided. Likewise, a 1Password client will generally not ask for data the server would refuse to supply. Throughout this document, we’ll typically mention the deepest layer of enforcement only.
The administrators have come to be wary of how the dog Patty (see Story 8 for background) treats data. They want Patty to have access to the password for the dog door (they want her to be able to leave and enter as she pleases), but they don’t want Patty to give the password to any of her friends should her paws accidentally press the Reveal button.
So the administrators limit Patty’s ability to reveal the password. She can fill it into the website that controls the dog door (she lives in a somewhat unusual household), but she can’t accidentally press 1Password’s Reveal button while her friends are watching. This is protected by client policy.
But Patty is a clever dog. After she uses 1Password to fill on the website, she uses her browser’s debugging tools to inspect what 1Password has inserted. She gets the password, and tells all her friends so they can come and visit.
The house is suddenly full of Patty’s friends running wild, and the administrators have learned an important lesson: Client policy controls are easily evaded.