Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Authentication and the Have I Been Pwned API

troyhunt.com

Post reply on HN
Print view View original

31–40 of 125 posts

Re: Authentication and the Have I Been Pwned API

#31

Post by skybrian »

DINKDINK wrote: post #28

All the ways congestion controls are implemented on the web lead to a cognitively infantilizing UX, privacy violations, and even "skynet" enabling[1] (hyperbolic but nothing stopping it from happening). "Are you really human? What's: 3 x 9" "Can you click on images of buses?, hmmmm don't believe you're human still, can you click images of stores, hmmm now bikes, hmmm now vehicles, oh I didn't mean all vehicles I just…

That would only solve paying for services if you are an amoral service provider and don't care where the money really comes from as long as you get paid.

It doesn't do anything for people who don't want their services used by bad actors, which is increasingly the case these days - see all the people concerned about privacy and how big tech companies use their data. It's not going to help for anything social where you are trying to promote pro-social usage and discourage anti-social usage, however you define it.

Those concerns inevitably lead to things like "know your customer" and supply-chain policing. You can still build nice services, but not anonymous ones.

The issues are pretty much the same as TOR. Some people are willing to run TOR nodes because the good outweighs the bad, others get squeamish about child pornography and say: no thanks.

And that's why it's an API. If the "have I been owned" database were harmless and there were no concerns about bad actors, it would be a torrent, not a service.

Re: Authentication and the Have I Been Pwned API

#32

Post by smacktoward »

geddy wrote: post #23
sucrose wrote: post #19

Why are bad actors abusing the API? What benefit does it give them to just be able to check for leaked data on e-mail addresses? Especially when it doesn't actually provide the leaked data...

Perhaps they hammer it inefficiently or simply too often, possibly without even realizing it?

Never underestimate the potential impact of stupid people in large numbers.

Re: Authentication and the Have I Been Pwned API

#33

Post by zaroth »

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 into a list of every service I’ve ever subscribed to.

Whether or not it’s possible to scrape that information together, is it really something that should be available to pull over an API for a million emails a month?

Note this is very different information than the password breach count, which gives you an approximate count of how many times a given password has been breached, and works as a proxy for password strength without disclosing any PII.

Re: Authentication and the Have I Been Pwned API

#34

Post by denzil_correa »

jawns wrote: post #6

I wish the post made more clear, ideally right at the top, that the new fee applies only to third-party apps that access the HIBP API, not to end users whose email addresses are being checked against the API. You have to read through the post a bit before that becomes clear. Individual users who just want to figure out whether they've been pwned will not have to pony up the cash. They can still visit https://haveibee…

Bury the lede.

Re: Authentication and the Have I Been Pwned API

#35

Post by mehrdadn »

ksahin wrote: post #10

"After 4 and a bit years, by far and away the most popular method with an uptake of more than 90% is versioning via the URL. So that's all V3 supports. I don't care about the philosophical arguments to the contrary, I care about working software and in this case, the people have well and truly spoken. I don't want to have to maintain code and provide support for something people barely use when there's a perfectly vi…

Funny thing is here I am wondering why he didn't pass a query parameter instead of altering the path or adding a header to version the API... does anyone know? It has the advantage of being clickable while not implying the resource is different.

Re: Authentication and the Have I Been Pwned API

#36

Post by jtbayly »

dustinmoris wrote: post #27

> One thing I want to be crystal clear about here is that the $3.50 fee is no way an attempt to monetise something I always wanted to provide for free. If this was true, then all revenue made from those 3.5 would get donated to a worthy cause, not donated into Troy's own pocket. I am not saying that he shouldn't monetise it, but please let's be honest about it. > The point is that the $3.50 number is pretty much bang…

This is such a clearly useful, legitimate service. You cannot tell the bad guys to delete your data. The next best thing is to be alerted when your data is found in a bad guy’s trove.

Re: Authentication and the Have I Been Pwned API

#37

Post by pionar »

theandrewbailey wrote: post #18

> Making an authenticated call is a piece of cake, you just add an hibp-api-key header as follows: > GET https://haveibeenpwned.com/api/v3/breachedaccount/test@examp... > hibp-api-key: [your key] Wouldn't the standard Authorization: Bearer header be more compliant?

No, because it's not a bearer token.

Edit for clarity: A bearer token [0] is a concept for OAuth. This is not OAuth.

[0] https://tools.ietf.org/html/rfc6750#section-1.2

Re: Authentication and the Have I Been Pwned API

#38

Post by jtbayly »

zaroth wrote: 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…

You’ve convinced me. I didn’t know anybody could lookup my info. I only want it for myself.

Only thing is, there are a couple of old email addresses I used to use that I don’t have access to anymore. I guess I just need to shrug at that at this point.

Re: Authentication and the Have I Been Pwned API

#39

Post by HereBeBeasties »

sucrose wrote: post #19

Why are bad actors abusing the API? What benefit does it give them to just be able to check for leaked data on e-mail addresses? Especially when it doesn't actually provide the leaked data...

Doesn't take much imagination to find a use.

Assume I find Anna's email address as part of a breach somewhere.

Hello Anna,

We value transparency and honesty highly at $p0wn3d_company. To that end, we're sorry to have to tell you that our systems were compromised by an unknown hacker recently. Although we believe that no personal data has been stolen, we are working with Government agencies and expert security consultants to determine the full extent of the breach.

As a precaution we are asking our customers to change their passwords, which you can do by clicking on >this link here to a website that looks like ours but is actually owned by a hackerEtc.

Re: Authentication and the Have I Been Pwned API

#40

Post by floatingatoll »

theandrewbailey wrote: post #18

> Making an authenticated call is a piece of cake, you just add an hibp-api-key header as follows: > GET https://haveibeenpwned.com/api/v3/breachedaccount/test@examp... > hibp-api-key: [your key] Wouldn't the standard Authorization: Bearer header be more compliant?

See also elsethread about "not a token" — but, also:

> There's a couple of these and they're largely due to me trying to make sure I get this feature out as early as possible and continue to run things on a shoestring cost wise

Using the Authorization header can cause significant problems with both clients and servers, and also might unintentionally permit browsers to directly query the server if they can be convinced to provide a bearer token.

Using a custom HTTP header sidesteps both client and server issues altogether and closes the door on browsers direct-querying the API, which could be considered a positive by the site operator.

Post reply on HN