Hacker News Reader

Comment by atleta | Hacker News Reader

While you are correct that sender authentication is an important requirement, I think you are mixing two things. Having end-to-end encryption is one thing, sender authentication is another.

It does matter what you trust BitWarden with. If you just rely on them for sender authentication it doesn't mean it's not encrypted E2E. They won't be able to look at your data, but are right, they could forge messages. However, even then you can do the authentication yourself, inside the message. E.g. send a hash through an alternate channel, or if it's too complicated (because you may argue that you could just use PGP with people who know how to verify a hash) then include an agreed upon password in the encrypted message. It's not ideal of course and their app could support these (like you say) but it doesn't mean you have to trust them or that the message is not encrypted end-to-end.

View on HN

>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.

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