Same... I'm not sure if this is possible via HIBP but I feel like we should be able to look at the data ourselves, at least at the parts that pertain to us?
> The questions that are harder to answer (and again, I know these will come up based on prior experience), are what the password is that was exposed, what the website it appeared next to was and, indeed, if it appeared next to a website at all or just alongside an email address. Right at the beginning of this project more than a decade ago, I made the decision not to load the data that would answer these questions due to the risk it posed to individuals and by extension, the risk to my ability to continue running HIBP. We were reminded of how important this decision was earlier in the year when a service aggregating data breaches left the whole thing exposed and put everyone in there at even more risk.
Yeh I figured it was a choice, but thought maybe Troy could make it so we could only see the data that relates to us, maybe by sending a verification email, similar to how he verifies domain searches.
I think the point is that building any kind of tool to enable this is surface area for an attack. The design choice is to remove any possibility of that happening at all.
It lets you know that it's included in a leak of some kind. I think the issue with these combolists is that they're mostly other leaks bundled up for resale and most or any info from them isn't reliably attributed to any website in particular.
I would also appreciate a coocoo table with all known pwned passwords. To at least use it on frontend on sign up/password change form to help reduce credential stuffing efficiency.
