data breach report broken with current webvault

[tycho]

The current git version (and v2.9.0 release I believe) of the web vault uses this request to get the Have I Been Pwned breach report:

https://bitwarden.example.com/api/hibp/breach?username=username@example.com

Right now bitwarden_rs doesn't know how to respond to this, so it just causes a 500 error response.

I saw this on Reddit, where the Bitwarden developer explains that the HIBP API changed so now the HIBP query happens on the Bitwarden server side:

https://old.reddit.com/r/Bitwarden/comments/ahm5wc/haveibeenpwned_breached_account_lookups_denied/

[dani-garcia]

I've added this in https://github.com/dani-garcia/bitwarden_rs/commit/a79745956025de9d3c859f6eec9eb329f2717c24, but I'm getting 403s from the server, I'm not sure if it's only me though.

According to https://haveibeenpwned.com/API/v2#UserAgent and https://haveibeenpwned.com/API/v2#Authentication, the only thing that needs to be done is setting the User-Agent, so I don't know if the problem is that it doesn't work or that I got temporarily blocked while testing the service.

Upstream also sets an API key, client id and client IP, but the documentation doesn't mention anything about those three.

I'd appreciate if someone can give it a test to see if the problem is on my side only.

[tycho]

Looks good to me:

2019-01-20 07:31:11][rocket::rocket][INFO] GET /api/hibp/breach?username=username@example.com application/json:
2019-01-20 07:31:11][_][INFO] Matched: GET /api/hibp/breach?<username> (hibp_breach)
2019-01-20 07:31:11][rocket::rocket][INFO] GET /api/hibp/breach?username=username@example.com application/json:
2019-01-20 07:31:11][_][INFO] Matched: GET /api/hibp/breach?<username> (hibp_breach)
2019-01-20 07:31:11][reqwest::async_impl::response][DEBUG] Response: 200 OK for https://haveibeenpwned.com/api/v2/breachedaccount/username@example.com
2019-01-20 07:31:11][reqwest::async_impl::response][DEBUG] Response: 200 OK for https://haveibeenpwned.com/api/v2/breachedaccount/username@example.com
2019-01-20 07:31:11][tokio_reactor][DEBUG] dropping I/O source: 0
2019-01-20 07:31:11][tokio_reactor][DEBUG] dropping I/O source: 0
2019-01-20 07:31:11][_][INFO] Outcome: Success
2019-01-20 07:31:11][_][INFO] Outcome: Success
2019-01-20 07:31:11][_][INFO] Response succeeded.
2019-01-20 07:31:11][_][INFO] Response succeeded.

I wonder if the API key is needed if you exceed a certain number of requests?

[dani-garcia]

Great, thanks for testing it!

Yeah, that may be it, but it's strange, usually when you hit a rate limit the code is 429 Too Many Requests and I was getting 403 Forbidden.

Oh well. At least we know the code works, so this can be closed. PD: It's a bit strange that the vault 2.9.0 is already deployed, but not released in GitHub.

[tycho]

Yes, it is strange. I think maybe the developer just forgot to git push --tags.

[mprasil]

I think upstream Vault basically runs on master and 2.9.0 will be released later on. That was my experience in the past.

[d19dotca]

Are we waiting on 2.9.0 master to be released then before this is actually fixed for bitwarden_rs web vault? Or am I missing something in the latest bitwarden_rs build? I ask because I am still running into this issue but see this reported issue as "closed" already.

[dani-garcia]

I created a vault build that should contain the breach fixes last week (https://github.com/dani-garcia/bw_web_builds/releases), but I marked it as prerelease waiting for the 2.9.0 release. Currently, the docker images don't use it, but maybe we should switch over anyway, seeing as the official vault is already using 2.9.0.

[d19dotca]

I agree, I think if we can use the latest code from the bitwarden/web project, it should be fixed then. It's not an issue in the main bitwarden project anymore (it used to be for a short bit though after hibp changed it's API around).