Authentication and the Have I Been Pwned API(troyhunt.com) |
Authentication and the Have I Been Pwned API(troyhunt.com) |
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.
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.
Are there additional benefits of the public api that on balance benefit the public more than attackers?
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.
Just think of the number of clueless users who would mark such a notification as spam, and the number of old, dead addresses, some of which are now spamtraps.
edit: clarify bulk vs. individual notifications
> GET https://haveibeenpwned.com/api/v3/breachedaccount/test@examp...
> hibp-api-key: [your key]
Wouldn't the standard Authorization: Bearer <key> header be more compliant?
> 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.
Edit for clarity: A bearer token [0] is a concept for OAuth. This is not OAuth.
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://haveibeenpwned.com and get that information for free.
I'd love to know how to get a hosting provider to actually answer such requests. (I hope the answer isn't just "be high profile". I'm hoping the answer is more like "know the right people to contact or the right phrasing to get through first-line support".)
I've reached out to hosting providers before, providing clear logs of malicious activity, and either gotten no answer, or occasionally gotten a rote "prove it came from us" that would trivially have been answered by actually reading the logs.
(Examples of such logs include SSH brute-forcing attempts, HTTP logs showing attempts to exploit web-app security holes, and spam headers showing the IP that contacted my provider's mail server.)
I've mostly stopped even trying, due to the near-zero response rate.
In an ideal world, I'd love to see reports like this lead to "we can confirm and we've shut down outbound traffic from that system until it gets fixed".
The only type of service providers I've ever had useful responses from are email/mailing-list service providers, many of which will very quickly investigate and terminate spammers.
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.
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.
Well said !
<Location /v3>
<LocationMatch ?[.*&]v=3(&|$)>
In previous blog posts he mentions that he gets 99.x% cache hits on Cloudflare, then also has a cache on his Azure service. He is sponsored by Cloudflare and Microsoft and doesn’t pay for the service unless something has changed since a few months ago. If that is still true, I don’t fully buy that he is actually spending money on Microsoft api hits as the post claims.
But, I like Troy and HIBP, so maybe I’m just too much of a skeptic :-)
Theres even a torrent file of all of them I won't link here...
I usually only see some
And when people ask about a latest leak, others disingenuously reply “just check YOUR email on HIBP what kind of person needs the database”
In such a case, the API may be saving them from needing to build infrastructure to accumulate the database and either distribute slices of the data or host their own API for their distributed software to use.
While the database may be valuable, they'd still have to invest a lot of time and some amount of money, face the same need to secure their API against exploitation by others, leave a stronger footprint leaving back to themselves, and have to depend on a service that is more likely to get flagged as a sure sign of suspicious activity than HIBP...
But you can justify a significantly more restrictive rate limit for a website form intended for individual mortal humans to check their own personal email addresses for breaches.
The API has to support request frequencies for legitimate usage that are obviously exploitable at a sufficiently small scale to attract a few exploiters...
That's already been happening. Many simply use HIBP as a starting point to pwning someone's online accounts. Now, Troy is just going to attempt to really profit off of the actions of those bad actors.
Edit: This is solely for password vetting during account creation and password reset (which will remain free/no-cost in the API).
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 hacker<.
Etc.
"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 meant autos and not motorcycles, here quick copy this token, oh it expired? Too bad. How about you click on images of buses for me..."
"Sorry, browsers that protect your privacy and location aren't allowed. We only allow users who are willing to deanonymize themselves."
"Well we all know /those people/ who come /that place/ are antisocial users"
"Here's your IP addresses back. Oh yeah, sorry about blacklisting them"
This is a comment about the meta issue Troy faces. If costs are rubegoldberg'ed to create a facade of "free", it's not actually free (even if user data isn't being sold). e.g. A median-wage (10e3USD/year) world worker spending 20 seconds solving a captcha has an opportunity cost of 0.03USD[2]. Further more, having to solve congestion issues by implementing requirements to use closed/inaccessible (credit cards) poorly programmable, sucks too. Additionally, if a congestion solution is ("I'd rather low-demand users have free access and high-demand users have expensive access) isn't solved by having a flat rate (which a "keep it low cost, mantra is incentivized to keep low"). There is market demand for: If your demands on my service are x, I'll give you back the $3.50 but if you consume y resources You have to pay Z.
Wouldn't it be great if there was a way machines could own money, send it over a layer-2 network, that was open, cheaper than credit cards, faster than L1 bitcoin, and get your money refunded if you didn't demand excessive server resources, all while not using game-able "good users come from here" privacy violating algos?
This is why micropayment using layer-2 bitcoin on the Lightning Network has significantly-valuable, latent, economic-coordination implications. Micropayments aren't about paying for 1/1000 of a peanut. They're about obviating all the engineering, social, product costs dealt with dealing with Marginal Value, Marginal Cost issues. BAD: The marginal cost of anti-DoS counter measures can always be above the marginal value of deploying them ("listen folks it costs to much to keep this service running, we'll have to shut it down". UNSTOPPABLE: If a price is put on service requests (Services on Demand)[3] the marginal value will never be below the marginal cost ("I can keep this AED locator map service running because I know a spamming request will incur costs above my production costs").
In a future where L2 Bitcoin payment/Lightning client infrastructure is prevalent, gone will be the days of annoying, productivity-draining captchas, attribute-discriminating access. Troy could charged a 0.01USD "bond" payment for a request (Which he could give back fast and costlessly to a low-demand user). Meaning the 14e3/min requests for 3 hours would have required the high-demand user a payment of $25,000USD[4].\
0.01USD refundable payment for honest users.
$25,000 USD penalty for high-demand "spammer"
[1] https://i.redd.it/pb5nggw3rulz.jpg
[2] 20/60/60 * 5
[3] https://medium.com/@soddiraju/the-not-so-micro-potential-for...
[4] 14e3 * .01 * 60 * 3
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 on the mark for the cost of providing the service.
The cost of the service is the actual final bill which has to be paid for this service, taken into account all the free credits Troy gets as a Microsoft Regional Director, free credits for hugely advertising Azure at every occasion, free credits from Cloudflare for constantly advertising for them, the tax which he doesn't pay as a registered company, etc. divided by the actual amount of customers who use the API. This cost could be much more, or significantly less than $3.5. If Troy wanted to be more transparent then he could, but given that he is very secretive and very selective about the bits of information he shares around all of this, my guess is the cost is much less than what Tory makes everyone believe.
Overall I don't think it is ethical to monetise a service which is built on stolen data. There is a good chance that Troy holds data on me, my parents, my sister, wife and lots of other people who's data have been breached over the years and have no idea who Troy is, what the heck HIBP is or even know how to contest or request from Troy to remove their data from his service, yet it's being used for monetisation.
There was never a consent from anyone to hord our data. It's stolen, and only because stolen data is easily discoverable on the internet doesn't make it alright to actively search, store and monetise that data. It's still stolen and should get deleted from everywhere.
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.
My comment illustrates precisely how such an incentive structure denies high-resource demand users.
>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.
This makes no sense to me, sorry. Are you claiming that anyone who accepts cash payments is amoral because a euro/dollar bill could be stolen and equivalently people who accept bitcoin payments are amoral because they don't surveil their customer's financial history?
If you want to continue using legacy technology, that's fine. If you're not comfortable with your bits being in a computer, that's fine. But it'll be slower, more expensive, and less transnational etc.
There are no bad guys just selfo serving people.
What do you really know about Troy and his service? Really just what he wants you to know.
For example, Troy stores extremely valuable information about millions of people without their consent. A lesbian women in the Arabs, who might have had her credentials breached on a gay forum, who also has a gambling addiction and had her password breached on a gambling website and on another dating website for prostitution services might not want some Aussie guy selling all that information about her to anyone who pays him money. There is nothing, absolutely nothing ethical about this!
My sister does not know anything about Troy, I showed her his Twitter profile and the first things which stood out to her:
- Old man
- Orange skin like Trump
- Loves to show off outdated cars
- Making occasionally snarky comments about Indians, Indonesians and other Asian people, always suggesting that anything illegal is coming from those countries
- Constantly tries to self validate himself by bragging with something expensive he's recently bought in life
- Very capitalistic and money focused individual
It's not great optics for people who have never seen his blog. His blog is just marketing at the end of the day. There is no regulation, no actual organisation or anyone who can be held accountable for gross mishandling of the data.
It's just an old Aussie guy who stores hordes of stolen data on his private laptop and in his private cloud and sells it to other people who clearly gain benefit from collecting that data from his service.
There is trust and naivity, and in this case anyone who doesn't find it slightly dodgy is simply naive. Sorry, but that is the reality.
But I realize the wording in the original post is a little ambiguous; I had read "provide ... directly" as implying "push", but that may not be the case, and if so my comment above is not relevant.
Depending on what you're providing, maybe that's fine. In the open source world, we give away code all the time, to everyone. Most public reading material is fine.
But services differ and for some services of interest to bad actors, many people are concerned about the consequences when they do business.
Of course, if there's no bad guys, I guess you don't see any problem. That's one weird point of view.
That's the issue with your idea though. For the current status quo all I need is a valid credit card and the ability to type "curl -H "hibp-api-key: <whatever the key is>" https://haveibeenpwned.com/api/v3/breachedaccount/test@examp...
I can have that done in less then 60 seconds, it fits his threat model, and can be done in any language with a tcp lib.
Your idea isn't bad, it just does not fit the problem.
HIBP doing the same thing with less friction for people who are trying to learn about security is probably fine in comparison.
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 counts and the type of hashing that was performed.
And at the same time the information being “bartered” is private user information and not merely identifying a flaw in a commercial product.
I fail to see how an API into the HIBP database can be justified under the concept of full-disclosure. Particularly when the service could have been implemented as an email report to the queried email address.
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...
That same section of the document describes other scenarios, like a hosted service or a CLI tool, that do not involve a proxy service.
Imagine it being $500/month to access HIBP, because that's the alternative, not some, "everyone agrees to only use this info for good".
I can’t think of an example.
Therefore, having that info cost more is better. Having it cost a lot more is a lot better. (I’m assuming I can still get access for free by having provided directly to my email address.)
By virtue of the fact that this info is widespread, you have no choice but to take actions to protect yourself from this information. That means the information becomes useless.
You are, in a way, being shamed into acting, through public disclosure. So no, having that info cost is not more better, it's more worse.
Furthermore, it is not an option to only let you have this information. That ship sailed when the breaches happened. You don't get access to this information for free, you don't get to control the dissemination of this information, you are powerless. You're acting like HIBP is the only way people can find this info out; it's not. That $500 price tag is just for you. People who are more skilled than you or I at collecting this info get it for free, and that's never going away.
Your bank could check emails attached to customer accounts and work with affected customers to ensure their bank account access is secure.
You employer could check for leaks of accounts using corporate domains. They could check leaked passwords against known last 5 to see if there are active threats.
Like it or not, there is an rfc for this and using it for anything else would be code smell at best
> Like it or not, there is an rfc for this and using it for anything else would be code smell at best
No but every OS that uses windows can call them windows....
Can you link to any tool which uses bearer tokens and doesn't grant them through oauth2?
Or it's internal, please explain how the token is obtained.
I haven't seen any to date but I guess I could be wrong
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.
Full disclosure can also protect previously unaffected / potential future customers, by warning them of companies that have been so lax with their security that they've been breached.
So to achieve a comparable upside to full disclosure, HIBP needs to also make aggregate data publicly available. Which they do:
These are bearer tokens, in that the bearer gets granted access by that token alone.
You happen to send it along in a Basic authentication in HTTP instead of as an Authorization header, but it is a bearer token all the same.
No OAuth2 flow required.
Yes: https://www.pelion.com/docs/device-management/current/integr...
(I know I've seen and used many others, but Pelion comes first to mind because I used to work on it.)
Authorization: Bearer <API Key>.
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.
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.
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.
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.
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.
Well, I take issue with that.
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.
