[GH-ISSUE #1399] users.equivalent_domains field is cleartext in the database #939

New issue

Closed

opened 2026-03-03 02:04:50 +03:00 by kerem · 3 comments

kerem commented

2026-03-03 02:04:50 +03:00

Owner

Originally created by @jtackaberry on GitHub (Feb 17, 2021).
Original GitHub issue: https://github.com/dani-garcia/vaultwarden/issues/1399

Subject of the issue

users.equivalent_domains is cleartext in the database which could leak information about sites users visit (under the assumption that users will enter domains here that they visit).

Your environment

Bitwarden_rs version: 1.19.0
Install method: Docker image
Clients used: N/A
Reverse proxy and version: N/A
Version of mysql/postgresql: N/A (sqlite backend)

Expected behaviour

The field should be encrypted and opaque to the admin, or if this data is required to be cleartext for some backend functionality to work, that should be documented somewhere, and ideally there should be a big warning box on the front end where this is configured saying this information shouldn't be considered private.

(Though as the web client isn't your code I'm not sure if this is feasible, but it's certainly preferable of possible.)

Actual behaviour

The field is stored in plaintext and users would incorrectly assume, given the rest of Bitwarden's security posture, that anything they enter there would be encrypted on the backend.

Originally created by @jtackaberry on GitHub (Feb 17, 2021). Original GitHub issue: https://github.com/dani-garcia/vaultwarden/issues/1399 ### Subject of the issue `users.equivalent_domains` is cleartext in the database which could leak information about sites users visit (under the assumption that users will enter domains here that they visit). ### Your environment * Bitwarden_rs version: 1.19.0 * Install method: Docker image * Clients used: N/A * Reverse proxy and version: N/A * Version of mysql/postgresql: N/A (sqlite backend) ### Expected behaviour The field should be encrypted and opaque to the admin, or if this data is required to be cleartext for some backend functionality to work, that should be documented somewhere, and ideally there should be a big warning box on the front end where this is configured saying this information shouldn't be considered private. (Though as the web client isn't your code I'm not sure if this is feasible, but it's certainly preferable of possible.) ### Actual behaviour The field is stored in plaintext and users would incorrectly assume, given the rest of Bitwarden's security posture, that anything they enter there would be encrypted on the backend.

kerem closed this issue

2026-03-03 02:04:50 +03:00

kerem commented

2026-03-03 02:04:51 +03:00

Author

Owner

@BlackDex commented on GitHub (Feb 17, 2021):

I don't know if that would help that much. If a user has favicon enabled this exposes that same information.

If you want to avoid this, then you are probably better off by just adding those domains to the specific ciphers as an add URL.

Also, this is something upstream doesn't encrypt either, else they would have encrypted it before sending it to the backend server.

@BlackDex commented on GitHub (Feb 17, 2021): I don't know if that would help that much. If a user has favicon enabled this exposes that same information. If you want to avoid this, then you are probably better off by just adding those domains to the specific ciphers as an add URL. Also, this is something upstream doesn't encrypt either, else they would have encrypted it before sending it to the backend server.

kerem commented

2026-03-03 02:04:51 +03:00

Author

Owner

@jtackaberry commented on GitHub (Feb 17, 2021):

@BlackDex yeah, I assumed upstream wouldn't have encrypted this either as obviously the protocol itself has this information passed in the clear.

One of the big differences between this and the favicons feature is that the latter is documented that it has privacy implications, and takes you to a page explaining what they are.

Again I know the frontend is entirely different, but in case you have some latitude as to what's displayed, or at the very least documenting it somewhere -- or perhaps this very issue will serve as that documentation (because I searched before I opened it :)).

@jtackaberry commented on GitHub (Feb 17, 2021): @BlackDex yeah, I assumed upstream wouldn't have encrypted this either as obviously the protocol itself has this information passed in the clear. One of the big differences between this and the favicons feature is that the latter is documented that it has privacy implications, and takes you to a page explaining what they are. Again I know the frontend is entirely different, but in case you have some latitude as to what's displayed, or at the very least documenting it somewhere -- or perhaps this very issue will serve as that documentation (because I searched before I opened it :)).

kerem commented

2026-03-03 02:04:51 +03:00

Author

Owner

@jjlin commented on GitHub (Feb 17, 2021):

It would be better to request this at https://community.bitwarden.com/c/feature-requests/5 so any changes benefit all Bitwarden users.

@jjlin commented on GitHub (Feb 17, 2021): It would be better to request this at https://community.bitwarden.com/c/feature-requests/5 so any changes benefit all Bitwarden users.

kerem referenced this issue

2026-03-03 08:53:16 +03:00

[PR #939] [MERGED] Fix attachment size limit calculation #2831