The Bitwarden Blog
Bitwarden Send - How it works
March 18th, 2021
Bitwarden Send is a new trusted method to directly transmit encrypted information to anyone. For a general introduction please see Introducing Bitwarden Send for secure one-to-one information sharing.
Similar to all of your Bitwarden Vault data, everything shared through Bitwarden Send is end-to-end encrypted. This means that Bitwarden cannot see the contents of your Send, whether that be a text snippet or a file.
One of the important components of Bitwarden Send is built-in automatic deletion. Because the sensitive data will be deleted, users can ensure their information does not linger, or remain in a system over which they have no control. For example, in a typical sharing model, once a piece of information is emailed or messaged, it stays in those systems often forever. Using the Bitwarden model, while the Send link may remain, it will no longer work, and the data attached to that Send will not stick around.
A Send object can be further protected with user configured parameters including:
- A deletion date when the Send is permanently deleted
- An expiration date when the Send link is no longer active, but remains in your Vault
- A maximum access count such that users will no longer have access once the count is reached
- An optional password required to access the Send
- A disable option, so that no one can access the Send if selected
A Send link might look like the following:
After the hash (
#), the Send ID appears, and then after the forward slash (
/) we find the Send encryption key.
It is important to note that
- The Send link is generated client-side and not on the Bitwarden server, so Bitwarden can never see the content of the Send.
- The link contains full access to the Send.
- If someone were to get the link, they could access and decrypt the Send on their client, unless the Send is also protected with a password.
It is normal to ask, "Why is it safe to transmit a Send link through insecure channels?"
First, end-to-end encryption ensures that Bitwarden as a service can never see the contents of your Send. In other words, Bitwarden has zero knowledge of your Send contents.
Second, if you password-protect your Send and communicate that password to the recipient through a different channel, then it doesn’t matter whether the main Send channel you use is secure, because your Send cannot be accessed by anyone or anything except the recipient.
It’s important to note that if you don’t password-protect your Send, and you transmit the Send link through a channel that could be compromised, then your Send could be compromised. That said, you have the option to limit the time when the Send is active by setting an expiration or deletion time and date. Or, of course, simply add a password and transmit that through a different channel. For example, you could transmit the Send link through email, and use a messaging service or voice call to share the password.
Finally, by design, every Send link eventually becomes inaccessible based on user parameters. So, if your email at the time of transmission is secure, but later is exposed to a hack, a Send with a short deletion window will not be around to be uncovered.
The Send password, added optionally to each individual Send, is completely distinct from the Send key used for data encryption.
The Send password is user-defined, optional, and is a basis for authentication on an individual Send.
The Send key is auto generated, required for Send use, and facilitates the encryption and decryption of the Send data.
The Mozilla foundation has a helpful article on understanding the elements of a URL. Most important is the identification and explanation of the Anchor (or hash/fragment), and how that is treated.
It is worth noting that the part after the #, also known as the fragment identifier, is never sent to the server with the request. - Mozilla.org
With a Send URL, we can show the following breakdown
Anchor/fragment/hash - #SendID/SendKey
The anchor/fragment/hash is not sent to the server. Rather this information is used locally within the browser to identify and decrypt the Send.
Let’s explore the steps of a Send request based on this example Send URL
- Requests to get the website from the server at https://send.bitwarden.com
- Returns the website of the Send Access Page to the browser CLIENT
- Locally, the Send Access Page parses the URL fragment/hash and retrieves the Send ID (mS2LfeyK3xn3fVEQXzYnnhM2unTC) and the Send Encryption Key (Hayk8N7x792Ydx3wYD4cPfMEBXAU)
- Requests to get the Send data from the server with the Send ID (mS2LfeyK3xn3fVEQXzYnnhM2unTC)
- Returns the encrypted data for the Send object to the browser CLIENT
- Locally, the Send Access Page decrypts the Send object using the Send Encryption Key (Hayk8N7x792Ydx3wYD4cPfMEBXAU)
The sequence above is detailed graphically in the image below.
For advanced users there is one additional method that can provide even more protection. Since the Send ID and the Send Encryption Key are part of the anchor, and visible in plain text, they can be manually separated and shared through different channels.
This would understandably require the recipient to be very familiar with how to handle these pieces of information and so we would only recommend this approach with colleagues who are familiar with Bitwarden Send to start.
For Bitwarden Send documentation, please visit https://bitwarden.com/help/send/.
Bitwarden Send is available across all Bitwarden clients and text-only Send capabilities are included in our Basic Free Account. You may sign up for a Premium or Business Account to enjoy using Send for text and files. More information on Bitwarden plans is available at https://bitwarden.com/pricing
Back to Blog