Definitions

As a security product features can often be tweaked or adjusted in the name of "security". This is a very broad term, with unclear meaning, sometimes leading to constantly shifting goals. Further, when communicating to another engineer, or to product about an intended feature, its implementation and constraints, the communicating parties may have a different view of what they assume an attacker to be able to do, and what they want to achieve, possibly even not having anything they want to achieve, just the notion of "I want a secure product".

A formal approach here is needed: to aid in communication and to also provide a clear set of goals to achieve. This applies both to ad-hoc conversations in which the participants don't yet share a common understanding of security goals and the assumed attacker, but it also applies to long-standing assumed security we want to achieve for our clients, communication protocols, and cryptography. This is not limited to cryptographic topics.

The security definitions introduced here are based on those in the book Introduction to Modern Cryptography; it aims to establish what attacker model is considered and what security goals are hoped to achieve. The security definitions therefore are made up of two parts:

Threat model

Describes the capabilities of an attacker; that is, "what can they do", but not "how can they do it". It should communicate the capabilities we assume an attacker to have for that specific scenario. As appropriate, justifying this threat model helps all parties understand why it is reasonable to assume this. By default, an attacker is assumed to be able to do nothing, and the threat model adds capabilities. However, sometimes it can be helpful to add restrictive capabilities e.g. "attacker does not control the client's code", if participants otherwise take this for granted.

✅ Good	❌ Bad
Attacker has full control over the API server and database	Attacker cannot use AES timing side-channel attack to infer client secret on unlock (CVE-ABCD)
Attacker does not control the client's code	Attacker cannot try the 4 digit PIN 10000 times
Attacker has read-only control to the traffic to the API server after time T	Attacker cannot inspect TLS payloads with a MITM proxy

Security goals

note

"If you don't know what you want to achieve, how can you hope to achieve it"

To get from a vague notion of security to a set of goals we can measure, and possibly provably achieve, we need to define a clear set of security guarantees. These should describe -- based on the threat model -- goals we want to provide for a protocol / feature / application component; in other words, things we don't want an attacker to be able to do.

✅ Good	❌ Bad
An attacker should not be able to gain access to plaintext passwords*	It should be secure
An attacker should not be able to set a client-side key into a state, where they know at least 1 bit of key material	It should be impossible for an attacker to break the PIN
An attacker should not be able to distinguish between a randomly encrypted blob string and a "Credit Card" login item	It should use military grade encryption

*There is one underlying assumption always made when talking about security definitions in the context of Bitwarden's encryption. It is always true that an attacker can gain access to plaintext passwords if they have the same knowledge and possessions as a user. For instance, an attacker that guessed a users badly chosen password. We cannot protect against that, therefore we do not consider it breaking our security definition.

Compared to cryptographic proofs we make some simplifications. We generally omit "with non-negligible probability" which would usually occur in cryptographic proofs.

Communication

Instead of a vague notion of security the above two concepts allow formalizing and clearly communicating the security definitions. Introducing formality and review lets us distinguish security issues from subjective opinions. Security issues are proven when -- given a threat model -- one can show that a security goal fails.

Updates and additions to security definitions are continuous:

• You come up with a baseline during initial development (shifting left wherever you can).
• You evaluate and revise it when there’s new work on the feature.
• You evaluate and revise it when evaluating each security issue against it.

The definition will change as the system changes. Making this a routine part of vetting those changes increases the chance that it’ll remain useful.

Terms

Vault data

The collection of a user's private information that they choose to store securely within Bitwarden's secure environment. This typically includes highly sensitive data such as:

• Passwords: Credentials for various websites, applications, and services.
• Usernames: Associated usernames for accounts.
• Secure Notes: Encrypted notes containing sensitive information that the user wants to keep secure.
• Credit Card Information: Payment card details like card number, expiration date, CVV, etc.
• Identities: Personal information such as names, addresses, phone numbers, and email addresses that can be used to autofill forms.
• Attachments: Any files uploaded by the user to be stored securely within the vault.

Vault data may also refer to less sensitive data such as metadata:

• Last Updated: The last time an item was updated.
• Created Date: The date an item was created.

User

An individual who uses Bitwarden to store, manage, and access vault data.

Client

The software application that the User interacts with to access their vault data. This includes the official Bitwarden web vault, desktop applications, mobile applications, browser extensions, and any other software provided by Bitwarden that interacts with the Bitwarden server to access or manage vault data.

Protected data

Data stored in a format that is unreadable without additional information. Usually synonymous to encrypted, but with additional expectations about how the key is stored. Encrypted data which is stored together with its decryption key in plain text is not considered to be protected, even though it is encrypted.

Communication channel

A medium through which two or more entities, such as processes, applications, or systems, exchange data or messages. This can include communication between components on the same machine, such as inter-process communication (IPC), or over a network, such as between a client and a server. Common types of communication channels include sockets, APIs, message queues, shared memory, and HTTP connections.

Secure channel

A communication channel that provides confidentiality and integrity for the data transmitted between two or more parties.

• Confidentiality: The data is unreadable to unauthorized parties, typically using encryption.
• Integrity: The data cannot be tampered with or altered without detection during transmission.

Trusted channel

A secure channel that also provides authenticity.

• Authenticity: The identities of the communicating parties are verified, ensuring that data is exchanged only between the intended parties.

Partially trusted channel

A communication channel where trust is asymmetrical, meaning only some of the parties trust the channel. One party may have verified the other(s) and thus trusts the channel, while the other party or parties may not have done so, making the channel trusted by one party but untrusted by the other(s).

Fully trusted channel

A communication channel where all parties have verified each other's identities. This means the channel provides confidentiality, integrity, and authenticity, ensuring that the data is secure, unaltered, and exchanged only between the trusted parties.

Data at rest

Any data that is stored on a device or medium that is not actively being used, processed, or transmitted. This includes (but is not limited to) data stored on disk on the user's devices, or on disk on the server side.

Data in use

Any data that is actively being used, processed or accessed. This includes (but is not limited to) data that is temporarily held in volatile memory (like RAM) for quick access, computation, or rendering.

Data in transit

Data that is actively being transferred from one location to another, such as between memory locations, processes, or between devices across a network.

Data exporting

The controlled process in which data leaves the Bitwarden secure environment unprotected. As a consequence the guarantees made by this document will no longer apply. The receiving party may or may not have its own guarantees.

Data sharing

The controlled process in which data is shared with another party within the Bitwarden secure environment.

Data leaking

The process in which data unintentionally leaves the Bitwarden secure environment unprotected.

Informed and explicit consent

The process by which the User is provided with all relevant information regarding an action, understands it, and agrees to the terms in a clear and unmistakable way.

• Informed: The person giving consent must have all necessary information to understand what they are agreeing to. All or parts of the information may be assumed to be implicitly provided/understood by the context in which the user is giving consent. This includes:
  • Purpose: A clear explanation of what the consent is for, such as how their data will be used or what actions will be taken.
  • Risks and Benefits: Disclosure of any potential risks, benefits, or consequences associated with their consent.
  • Alternatives: Information about any alternatives to consenting and what happens if they choose not to consent.
  • Rights: A description of their rights, such as the right to withdraw consent at any time without penalty.
• Explicit consent: Consent must be given clearly and unambiguously, typically through a direct and affirmative action, such as clicking "I agree" or a similar action.

Certify

Officially recognize (someone or something) as possessing certain qualifications or meeting certain standards.

Bitwarden secure environment

Any process or application that adheres to the "Security" section is treated as "within the Bitwarden secure environment".