Live data from Hacker News

Authentication and the Have I Been Pwned API

troyhunt.com

81–90 of 125 posts

Re: Authentication and the Have I Been Pwned API

#81
post #78
post #64

Earlier quoted context omitted.

This just feels like another iteration of the Full Disclosure debate.

I’ve never heard Full Disclosure concepts applied to serving stolen PII in an API. The reason is that the purpose of full disclosure is to shame the vendor into ensuring the patch is made, and to warn the user base that the attack is possible, while disclosing a flaw in a commercial product. In this case, we are not effectively doing either naming or shaming by publishing actual email addresses, rather than just user…

You left out the biggest part of full disclosure in my opinion. The reason for full disclosure is because those who are affected by a security flaw in a product they are using have a right to know about the dangers of that piece of software.

But once I put that down in writing I discovered you are right about the difference in this instance.

The person who has the right to know about the flaw in this instance is the list of people whose accounts were compromised. Giving it to the general public is to further victimize them, rather than help them protect themselves.

Re: Authentication and the Have I Been Pwned API

#82

Earlier quoted context omitted.

I'm not sure how browsers using the API would be a concern. Someone paid for the key, so it should be up to them to use it how they please (within rate limits).

Allowing browsers to query directly would break the terms of engagement specified by the site operator, who specified that a proxy shall be used to concentrate end-user requests for a given paid key. That’s their right as service operator. I can construct plausible scenarios why this is a sensible choice, but the underlying point is that they clearly regardless made that choice after thinking it through.

That’s not a requirement specified anywhere. The “Protecting the API Key“ section talks about using a proxy specifically in the context of client-side applications (think of things like 1Password that integrate w/ HIBP), where embedding the API key into the app is obviously undesirable. In those cases, using a proxy allows managing the request volume and injecting the API key.

That same section of the document describes other scenarios, like a hosted service or a CLI tool, that do not involve a proxy service.

Re: Authentication and the Have I Been Pwned API

#83
post #64
post #63

Earlier quoted context omitted.

As discussed elsewhere in this thread, there are real benefits provided to bad guys by allowing them to look up this information about anybody in a central location.

This just feels like another iteration of the Full Disclosure debate.

It feels that way, but there is definitely a different utility value in “searchable by the whole world” and “leaked in obscure formats in small nonpublic forums”.

Troy has absolutely added value here, although 100% of the data is all “public” from having been leaked already.

Searching over data that was publicly available some time in the past (but isn’t now) is also a value, sort of like time-shifting of the publicness of the data...

Re: Authentication and the Have I Been Pwned API

#84
post #82

Earlier quoted context omitted.

Allowing browsers to query directly would break the terms of engagement specified by the site operator, who specified that a proxy shall be used to concentrate end-user requests for a given paid key. That’s their right as service operator. I can construct plausible scenarios why this is a sensible choice, but the underlying point is that they clearly regardless made that choice after thinking it through.

That’s not a requirement specified anywhere. The “Protecting the API Key“ section talks about using a proxy specifically in the context of client-side applications (think of things like 1Password that integrate w/ HIBP), where embedding the API key into the app is obviously undesirable. In those cases, using a proxy allows managing the request volume and injecting the API key. That same section of the document descri…

I look forward to clarification someday from the operator - but that custom header will still block non-extension browser-side calls in v3, and I bet the ACAO header isn’t present to allow it either.

Re: Authentication and the Have I Been Pwned API

#85
post #33

All this seems to be hinting more than ever, that the time to provide these results directly and exclusively to the email address being queried is approaching. Why is this API being abused? Because it provides valuable information—which took a significant amount of effort to curate—about an email address. The list of services which have lost my (hashed or not) password at some point ever in the past eventually turns…

Sorry, but the cat is out of the bag. HIBP is evening the playing field, making the data less valuable to those who have the skills to collect it.

It's the same thing as responsible/full disclosure; by making this information available to anyone (publish a vulnerability), you greatly reduce the power of those who have the skills to collect it anyway (the person who found the 0day).

So yes, this information needs to be available, or it'll only be some people who have it, not none, and those few people who do have it will be 10x stronger than they are now.

This is the old Antisec debate all over again, let's skip to the part where we end up agreeing generally that disclosure is better, okay? No need to relive 2009 or whatever.

Re: Authentication and the Have I Been Pwned API

#86
I feel his pain.

I run a SaaS with what I think is a pretty generous free tier (PhantomJsCloud dot com), and yeah, I have numerous people from all over the world doing their best to shit all over it:

- switching IP addresses every request to circumvent "demo user" rate limiting

- creating upwards of 100 fake accounts to get free credits ($0.05/day each account)

- embedding api calls into their webpages so their users ip address is used for "demo user" credits

- API driven credit cards and hijinks around that.

- using url shorteners to circumvent blacklisted domains

I'm not sure if it's a case of people being incapable of paying credit cards, or just their ethics allow stealing anything that's not bolted down?

I don't mind people signing up with a burner email address, but unfortunately most these abusers are too. I am going to be banning all throw away email accounts soon. And if that doesn't work (which it probably wont) I'm going to have to kill my free tier.

Re: Authentication and the Have I Been Pwned API

#87

I feel his pain. I run a SaaS with what I think is a pretty generous free tier (PhantomJsCloud dot com), and yeah, I have numerous people from all over the world doing their best to shit all over it: - switching IP addresses every request to circumvent "demo user" rate limiting - creating upwards of 100 fake accounts to get free credits ($0.05/day each account) - embedding api calls into their webpages so their users…

Can you do what the big cloud providers do, and demand a "real" phone number be verified for sign-up? Not impossible to beat, but more costly. Or maybe there's a market for paying customers somewhere between your free and paid tiers?

Re: Authentication and the Have I Been Pwned API

#88
I obtain the SHA1 hashes published by HIBP, load them into a bloom filter and use that for checks. It's super fast (constant time lookups) and avoids a network dependency/third party service. Here's working Go code:

https://github.com/w8rbt/bp

Edit: This is solely for password vetting during account creation and password reset (which will remain free/no-cost in the API).

Re: Authentication and the Have I Been Pwned API

#89
post #63
post #62

Earlier quoted context omitted.

The bad guys have access to it either way. That's the whole point: this is data that already leaked.

As discussed elsewhere in this thread, there are real benefits provided to bad guys by allowing them to look up this information about anybody in a central location.

There are plenty of other similar services that you can find that cheaply do the same thing AND provide you with the leaked hashes/emails.

HIBP doing the same thing with less friction for people who are trying to learn about security is probably fine in comparison.

Re: Authentication and the Have I Been Pwned API

#90

I feel his pain. I run a SaaS with what I think is a pretty generous free tier (PhantomJsCloud dot com), and yeah, I have numerous people from all over the world doing their best to shit all over it: - switching IP addresses every request to circumvent "demo user" rate limiting - creating upwards of 100 fake accounts to get free credits ($0.05/day each account) - embedding api calls into their webpages so their users…

Can you do what the big cloud providers do, and demand a "real" phone number be verified for sign-up? Not impossible to beat, but more costly. Or maybe there's a market for paying customers somewhere between your free and paid tiers?

My lowest paid tier is USD$10/mth. As my target audience are developers, I think it's hard to believe that any of them would really be unable to pay that, yet still gain value from my service.

Maybe I'm just a peace loving hippy but I'm rather shocked at the levels of abuse I see. I do want to enable paypal, just in case it's a lack-of-credit/debit card issue.

Post reply on HN