I can emphatically rule this out now due to the ever increasing risks of handling sensitive data in the system and making it searchable (yes, even partial card data is sensitive). More background here: https://www.troyhunt.com/here-are-all-the-reasons-i-dont-make-passwords-available-via-have-i-been-pwned/

Is there any update on this, I am very interested in seeing a service like this.

I like this idea as well and the way that you are presenting it Troy.

Thanks Dave and Christopher, awesome feedback guys!

I wouldn't want to hold a full card number and as Dave said, a full CVV is disallowed by PCI even at the best of times, let alone when we're talking about breached data. IMHO, only partials should be permitted such that in the event of all data being disclosed or any cryptographic protection being circumvented (i.e. hashes brute forced), the data is useless.

I also wouldn't want to ask for anything too sensitive from people using the service, even if hashed (which is a foreign concept to the vast majority of the audience). I'm still leaning towards a small piece of input data adhering to a pattern that identifies it as a CC (such as 4 digits) and then a slightly larger piece of response data that gives the user *reasonable* confidence that it's their card. I know that's very "lawyer speak", but it doesn't have to be a perfect match, rather just enough that there's a high degree of confidence that the card is a match.

Anyway, I've got a heap of data I can assess to try and find the right balance, keep the ideas coming guys!

I guess if you hashed the credit card number client-side before being uploaded to the server, then when you are importing leaked dumps you can just hash before you import.

This way raw credit data will never touch your database.

Regarding the questions you posted:
1) I wouldn't have a problem providing you a hash of my card number (provided I am able to submit only the hash. i.e. not giving you card number and you calculate the hash yourself even on client-side)
2) It would return when and where it was leaked

If I'm reading this correctly, the CVC should never be stored, even in an encrypted format.
https://www.pcisecuritystandards.org/pdfs/pci_fs_data_storage.pdf

I think due to the sensitive nature of CC then the only thing you can return is whether there is a match, and where the leak occurred.

Hmm. Good question. Don't know much about CC's. But i think that the interesting question is, 'what makes a CC unique'?
In case it's CC number and code: then let users search for CC number and only display CVC code in the result.
Then you could 1-way encrypt the CC number.

I'm really keen on this idea, the trick is working out what data goes into a search and what data comes out. People don't want to provide anything of any sensitivity (not should they) and I don't want to fall foul of PCI by holding data I shouldn't nor making it available to people that shouldn't have access to it and are then able to do something useful with it.

I've been giving this some thought for a while actually although I'm assuming today's #LulzXmas dump is the catalyst for this. In that dump we had CC data like this:

MasterCard XXXXXXXXXXXXXXXX 616 11/2017

No names in that case (although sometimes there are) so one option would be to store the card type, last four digits and expiry. People could search just on the 4 digits then get back the card type and expiry as well if it matches. That's by no means foolproof, but a positive hit would give you a reasonable degree of confidence in the result. Perhaps add a digit or two of the CVV as well for extra confidence, although I'd really want to check on the legalities of that too (i.e. requirements for storing the data). At least it wouldn't be personally identifiable so that's something.

For anyone who'd like to see this feature, I'd love to hear your thoughts on those two things:

1) What info would you provide in order to search CCs?
2) What info would be returned when a match is found?