Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

You can’t have it both ways. Either it’s widely available, or it isn’t.

If it’s already widely available then HIBP doesn’t accomplish anything. (It doesn’t anyway, since it doesn’t “shame” anybody except people who are already signed up, who only need and get their own info.) If it isn’t widely available then HIBP is helping people who are bad at collecting and using this information to do so.

We accept that from bug reports only because of the other benefits that come from releasing the info.



You're not getting that the alternative is much worse.

Your data is out there. Period. The end. You don't have control over that. All you're doing is trying to re-establish control over data you already lost.

The question now is, do you want it only in the hands of people who want to harm you, or do you want it in the hands of both people who want to harm you as well as people who want to help you?

You seem to only want bad guys to have your data. That's weird.


Thanks for the explanation. I get your point now. I did not find BFDM’s proposed benefits from white hats having access to be compelling. So what I’m struggling with is simply the idea that anybody could do something good with my data. If only bad can be done, then the fewer people spreading the data around, the better. Your presupposition is that some people will do good with it if they have access that currently only bad people have. Can you give an example of one of some of those good things?


1Password tells you which of your passwords have been part of a breach. Many other companies will suspend the accounts of anyone whose login information to their leaked as part of another site's breach.

Other websites won't allow you to use a password that's listed as a common password from the aggregated passwords in breaches.

Lots of studies have been done on password frequency, such as the top 100 most common passwords and what security people can do about their repeated use.

Based on your question however, I'm concerned you don't actually get my point. You're being forced into action, exactly how companies are forced into action, by the availability of this information. You have to change your password if it's easily available to anyone who uses this API and who has your email address, you no longer get to pretend it's not a big deal.


> 1Password tells you...

This is software acting as an agent of the effected user. 1Password could be authorized by the email holder to gain access to the API without making the information public.

> Other websites won't allow you to use...

This and the following example in your comment are discussing the breached password API, which is a completely different API that I specifically mentioned up-front as not compromising any PII.

I take zero issue with providing an API to see counts of how many times a password has shown up on breach lists, although I wouldn't use the API myself on any of my own passwords, because it leaks a 1-in-1-million discriminator to the actual password you are querying.


You don't get to take issue with any of this. Your information was already stolen! You have no say, the end.


So your fallback position is that it is perfectly legitimate to traffic in stolen PII. Got it.

Well, I take issue with that.


Yes, in some cases it's perfectly legitimate to "traffic" (terrible word choice) in stolen PII, that is correct.

And my "fallback" position is that it's better this way than the other way, where it's actually being trafficked, rather than your hyperbolic assertion that it is now.


Now apply this same thinking to the Equifax breach and millions of credit reports.

Now apply this same thinking to the OPM breach and security clearances.

Now apply this same thinking to medical records breaches.

I don't want anyone to have my data, but I resign myself to the fact that data security is, and never will be perfect. That does not mean I resign myself to the fact that all my personal data should be freely available to the entire world via a well documented REST API.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: