Questions Regarding the Security of the Send Function link

Ask the Community Password Manager
1

I have been thinking about the SEND function. It seems like the actual process of creating and transferring the file/text-message is secure. But what I have is questions about the transfer of the “Send link” to the recipient. That does not appear to be secure. After all, if the material being sent is too sensitive to be entrusted to an email, why should one assume that sending the link to that material using the same e-mail process in anyway protects the material. (Intercepting the link is the same thing as intercepting the material!)

Any thoughts on how to protect the link in the e-mail transmission?

Or should one use a password on the material sent using the Send function?

2

Best practice for sending via potentially compromised channels:

  1. Add a password to the Send and share the password via another channel
  2. Send the link without the key (everything before the last forward slash) and send the ‘key’ via another, unrelated channel
  3. Combine both methods above for maximum obfuscation :slight_smile:

We talked about this a bit during our Send webcast:

3

Should not these suggestions be in the Online Help under the Send topic? While it might not deserve a separate topic heading, it would certainly be appropriate to include it in the FAQ section.

4

Ask and you shall recieve @frank1940!

https://bitwarden.com/help/article/send-encryption/#send-security

2 Likes
5

Some questions Trey…

When you access a Send link, your article states that:

  1. The web browser requests a Send access page from Bitwarden servers.
  2. Bitwarden servers return the Send access page as a Web Vault client.
  3. The Web Vault client locally parses the URL fragment containing the Send ID and encryption key.
  4. The Web Vault client requests data from the server based on the parsed Send ID. The encryption key is never included in network requests.
  5. Bitwarden servers return the encrypted Send to the Web Vault client.
  6. The Web Vault client locally decrypts the Send using the encryption key.

Won’t the receiving party’s browser be passing the key to the server in Step 1 by clicking the link, as it’s part of the URL path? And if so, doesn’t that go against your statement in Step 4 about the key never being included in network requests?

6

Nope - nothing past the # is sent to the server - it’s universal browser functionality. You can verify it by watching the network traffic, too :wink:

Take a look at the video I linked, we talk about that aspect, too.

7

Ahh, I completely overlooked the anchor hash sign! Make sense now! Thanks.

1 Like
8

No worries! Thanks to @go12 for reminding me - we have a whole blog post about it!

:slight_smile:

1 Like
9

For the benefit of others. I played around with these two methods. My experience (and recommendation) is this:

Suggestion No. 2 is workable for people only with a very good technical background. (Just think about writing an explanation about how-to-do this for anyone with a limited technical understanding of browser nomenclature!)

Suggestion No. 1 should be usable by virtually anyone with the most basic computer skills. All you have to do is to tell the recipient in the first notification with the link that a password will be needed and how to get it. They then enter the PW in the box provided after the link loads, clicks on ‘Continue’ and the text/download occurs.

2 Likes