Hacker News Reader

Comment by upofadown | Hacker News Reader

>They won't be able to look at your data,

They totally could. All they have to do is trick you into sending a properly encrypted message to an endpoint under their control. Then they can decrypt the message, read it, properly reencrypt it for the entity you think you originally sent it to and then send it along.

Because they control the entire infrastructure and user experience this sort of thing would be trivial for them to do. An unsigned, anonymous PGP message (the equivalent) would actually be better.

View on HN

The thing works by encrypting a file using a password derived key (if I understand correctly) which then gets uploaded to their infrastructure. You get the url, containing the password (used to derive the key). There's no point and no way tricking you into sending it to them, i.e. setting up a MITM attack.

The client could just leak the key, but as far as I can understand, it's open source so you can prevent it by building it yourself (and either trusting others or auditing the code yourself too).

As the password is in the URL and you'll send the url through another channel, there is no way to MITM it (decode and then recode for the recipient). And wouldn't make sense anyway, since there was no key exchange, the recipient does not provide the sender with a key to use.

So yeah, they can absolutely look into your files - if they steal your key. (They could do it on the receiving side too, BTW.) But you can't sidestep this with any encryption software: you have to trust at least the encoding and decoding app. (Also, I think you can self host this.)

So it is just a "send the URL with a key in it" scheme? I totally missed that when rooting through the web site.

So regular encryption with insecure key distribution. Dunno what distinction they were trying to make with the end to end claim unless they think all forms of encryption are somehow end to end.

I guess the distinction is that, as I said above, they don't see the content (unless, again, the clients leak the key). And it is an important distinction, because everyone will emphasize the importance of an encrypted connection (read: https). Which is not e2e.

As far as I could decode, the point here really is just to add this service to help their users who came for the password manager. But I also had to watch their video to confirm that the key was in the url.

The password/key never hits the Bitwarden servers. Bitwarden servers are just storage buckets for encrypted payloads. The server is never involved in the encryption or decryption process; this is the case for Vault, and now Send. All encryption and decryption is handled exclusively by clients.

Note the URLs used; all the important bits are contained in the fragment (after the "#"). HTTP clients do NOT send the fragment to the server; a "#" and everything after it is stripped before being sent to the server. Bitwarden's Send URLs contain an identifier as well as the decryption key in the fragment. When you load the page, JavaScript is able to read the fragment; an async request is made to fetch the encrypted payload using the first half of the fragment (ie. the payload's unique ID). Then the client–in this case JavaScript–decrypts the contents using the second part of the fragment as the key.

Reply on news.ycombinator.com