When a single password is checked against HaveIBeenPwned, what gets exposed to them?

Using bitwarden, when a single password is checked by a user against HaveIBeenPwned, what gets exposed to them?

Do they receive the actual password, or a hash?
Do they receive the user’s IP address?
Do they receive the user’s email address?
Do they get identified as a bitwarden user?

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.


Thanks Ross. That’s genius. So much misinformation out there.

I’m still interested in the answers to the other questions (I added one more), but your answer is a very helpful start.

The code that talks to the Have I Been Pwned API is here :

So :

  1. They receive the first 5 digits of the hash
  2. They incidentally receive your IP address as this is used by the network to communicate. I don’t know if they associate it with the hash they receive or keep it in logs.
  3. They don’t receive your email address
  4. You may be identified as a BW user through the “User agent” field in the request. I don’t know what the browser sends when an extension makes a request.
1 Like

Thank you for answering some of the loose ends @Crocmagnon!

More about IP address and User agent in HIBP’s privacy policy:


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.

1 Like

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

1 Like

Thanks for the additional details @Crocmagnon.

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

For the record, the function that provides the “data breached report” is just under the password leaked :

The getHibpBreach is defined here :

By looking at the code, it seems that the username is sent in its complete form and in clear text.

1 Like

Is the bitwarden username sent via HTTPS? If so, would that prevent it from being sent in clear text?

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.

1 Like

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.

1 Like