PwnedPassword’s API documentation that bitwarden (and everything else) uses is there:
One of your question is easy to answer: pwned password receives the first five characters of the password’s hash, and replies with the suffic of the hashes that begin with those characters and that are found in the database. If your password’s hash is one of those in the response, your password has been “pwned”
So pwned password has absolutely no clue which password has just been tested, and the API users cannot guess which passwords are in the database except for their own.
Only the bare minimum logs required to keep the service operational and combat malicious activity are stored. This includes transient web server logs, logging of unhandled exceptions using Raygun, Google Analytics to assess usage patterns and Application Insights for performance metrics. These logs may include information entered into a form by the user, browser headers such as the user agent string and in some cases, the user’s IP address.
I just looked at the request headers when checking the passwords from the web vault using chrome’s dev panel. The user agent in the request sent to HIBP is as expected the “normal” user agent from your browser. I see nothing that could allow identification as a bitwarden user.
The email address is sent to HIBP when running the “Data Breach Report”, but not when running the “Exposed Passwords Report”.
@Ronan_Bossard Thanks Ronan. It’s interesting that the entire email address is sent when running the “Data Breach Report” and that no attempt is made to obfuscate it like with passwords.
Looking at the code that @Crocmagnon posted above, it doesn’t look like any email address is sent when checking a single password against the HIBP database. I haven’t verified it by analyzing the actual traffic, but I might spend a few minutes doing that.
Your bitwarden username is not explicitely sent. What is sent is the username(s) you want to check data breaches for, which may incidentally contain your BW username.
Here’s the function on the server which talks to HIBP API :
It uses the base url defined earlier in the file, and it’s HTTPS :
It has already been established that BW apps talk to BW server over TLS, so all the chain from your app/extension to HIBP uses secure communication to transmit your username.
BTW, unlike for passwords, the check for usernames is currently done by BW server. So if you use the cloud version of BW (not self hosted), HIBP knows you’re a BW user.
Again, looking at the code it seems that this HIBP check requires these request to provide an API key, which shouldn’t be shared on client applications, so that may be one of the reasons why this check is done by the server.
Ah, when you wrote “username”, I misunderstood that to be a bitwarden username, and not site username(s).
If I understand correctly, the site username(s) are sent in clear text, but they are sent through HTTPS. So even if that transmission is intercepted, it is still encrypted. Do you see any privacy/security issue there?
On the HIBP side, if they got hacked, all username(s) would get revealed during a check by a bitwarden user. I’m not sure, however, if that can be mitigated like it is for passwords (without transmitting large databases). I’m interested in hearing your (and anyone else’s) thoughts on that.
Since the breached usernames are anyway in a cleartext database that “everyone” can download, it wouldn’t make any difference for those.
However, for usernames that are not leaked it makes a difference since an attacker on HIBP side could get the plaintext usernames during a check, as you stated.
Furthermore, this tells HIBP that the username being checked is very probably a BW user, but I don’t think they do this kind of thing. I’m saying “very probably” since nothing prevents you from adding someone else’s username to your vault and then check it, but there is a very high chance that only yours exist.
If they used the same method as for passwords, this would solve this issue. But it’s not something Bitwarden team can act on, it has to be done by HIBP.
The communication itself is considered secure since it uses TLS. I wouldn’t add any more protection.