Different organizations have different security postures. Your list of hashes may be transferred into secure systems in text format where they are processed in order to match against internal password databases.

Unfortunately, despite the k-anonymity interface, exfiltrating even a partial password hash is forbidden. Given this use case, I believe it would be advantageous to provide incremental hash lists for every addition made to the database between major releases of the complete list. Daily, or even weekly would be good.

The objective would be to notify users immediately if the hash of their current password is ever added to the list rather than having an exposure gap (in this case from November 19th 2020 (V7) until v8 is released).

HIBP unlike other services like enzoic does not yet provide a way to find matches if the breach data contains medium to strong protected passwords.

To make that passwords searchable without cracking them the API needs to accept the username as input and returns a list of hashes together with meta information e.g. salt and hash algorithm. The client can then for all results use the provided hash algorithm for the password and compare it with the hash from the API result.

security notes:
1. you may want to add a second hash algorithm on top to avoid storing passwords with week hash algorithm in you database
2. you may search the username by k-anonymity model to protect privacy of users (nobody will see from API usage who registered on which site)

I know its a lot of work some more searchable passwords, so I am ok with paying for such a service.

With the current API, for the paste model it is mentioned that the paste date is only included if it is known, and that this value may be null.

Can you please consider adding a 'date reported' field to the paste model, which would simply be the timestamp of when a given breach is reported by HIBP. That would give a usable reference point as to the possible age / currency of the paste, in the event that the regular date value isn't known.

This would also be consistent with the breach model in the API, that differentiates between 'BreachDate' and 'AddedDate'. So in the pastes model, the 'PasteDate' might be null, but the 'AddedDate' would never be null

The Guntrader breach should not be publicly visible as the severity of that leak comes from it revealing the names, addresses and locations of UK gun owners. Guntrader is a site that is purely used to buy and sell legal firearms in the UK so 99% of those with an account have guns. The UK National Crime Agency are involved at a high level as this breach puts gun owners at high risk of criminal attack and theft of firearms by knowing who has them and where. Unlike some countries the UK has very strictly controlled firearms access and guns and their locations are not normally available to most criminals. Currently you can search this site for an email address to see if they are a gun owner which is potentially as bad as the original leak. By cross referencing information from social media and other leaks a full picture of gun ownership is easy to put together. Alternatively allow opt out for individual breaches.

So I've just been notified about the LinkedIn "scrape" and have verified that my data predates the Forbes breach. I have used multiple emails for LinkedIn over the years, and my current email is considerably older by a number of years than the HIPB alert might suggest.

I cannot be the first person to notice this, so it looks like this looks like some sort of peas porridge aggregation. It is notable that my current details are in the Forbes breach but the LinkedIn details are relatively ancient. I know you do not have a lot to go on for this but a nice to have.

Regarding the recent Ledger data breach, anyone that types a compromised email address knows that he/she has a ledger wallet and crypto. You are leaking to everybody the same information leaked by the hackers and you are compromising the security of that person by revealing the email, exposing him or her to phishing attempts and even to physical risk if the person that performs the search knows the identity of the owner. This is a very serious issue. Please consider sending the results only by email at least for these most serious data breaches where there is physical risk for the affected people.