users.equivalent_domains field is cleartext in the database #1480

New Issue

OVERLORD · 2025-10-09T17:16:44+03:00

OVERLORD commented

2025-10-09 17:16:44 +03:00

Originally created by @jtackaberry on GitHub.

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

OVERLORD closed this issue

2025-10-09 17:16:45 +03:00

OVERLORD commented

2025-10-09 17:16:48 +03:00

@jjlin commented on GitHub:

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: It would be better to request this at https://community.bitwarden.com/c/feature-requests/5 so any changes benefit all Bitwarden users.

OVERLORD commented

2025-10-09 17:16:49 +03:00

@jtackaberry commented on GitHub:

@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: @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 :)).

OVERLORD commented

2025-10-09 17:16:49 +03:00

@BlackDex commented on GitHub:

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

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/vaultwarden#1480