I don't mind seeing a duplicate here because this looks like a serious incident that may have been downvoted by Apify employees. I personally didn't see it til now despite checking HN very often.
If you check the thread you linked, Apify isn't being transparent about what data was in the leak. Someone posted it from an email they received and allegedly got downvoted, and then a response from an Apify employee.
(The title is fixed now, and I don't so much care about how much exposure the story gets on the front page as I do that we not lose track of the previous thread. I live in a blissful state of not even knowing what an Apify is.).
I feel like an asshole posting a criticism of the whole dependency category every time they get a critical vuln.
But if you are building an API service, you don't need an API Management dependency. And it's an additional attack vector. You (as in an engineer or as a company that provides an API service) need to do the actual undelegable job of building an API, just do the work, do the HTTP server, do the rate limiting, do the OAuth integration.
Verdict: Time to uninstall software in the category of API Management. That is, if you want to be the very best. If you want to be mediocre, sure use some middleware that provides API, slap some API into your software so that customers that ask for API have API. Otherwise, engineer an external Application Programming Interface into your systems.
The number of systems that will show me the API token more than once makes me realize that many haven't figured out it is just a long password and should be treated exactly as such.
Bleeping Computer's coverage is maybe a bit more detailed Apify rotates API tokens, prompts 2FA resets after breach (https://www.bleepingcomputer.com/news/security/apify-rotates...)
Duplicate, also editorialized title.
https://news.ycombinator.com/item?id=50469719
I don't mind seeing a duplicate here because this looks like a serious incident that may have been downvoted by Apify employees. I personally didn't see it til now despite checking HN very often.
If you check the thread you linked, Apify isn't being transparent about what data was in the leak. Someone posted it from an email they received and allegedly got downvoted, and then a response from an Apify employee.
(The title is fixed now, and I don't so much care about how much exposure the story gets on the front page as I do that we not lose track of the previous thread. I live in a blissful state of not even knowing what an Apify is.).
The link is different, yesterday's post seems to be the status page. This is a post-mortem
I feel like an asshole posting a criticism of the whole dependency category every time they get a critical vuln.
But if you are building an API service, you don't need an API Management dependency. And it's an additional attack vector. You (as in an engineer or as a company that provides an API service) need to do the actual undelegable job of building an API, just do the work, do the HTTP server, do the rate limiting, do the OAuth integration.
Verdict: Time to uninstall software in the category of API Management. That is, if you want to be the very best. If you want to be mediocre, sure use some middleware that provides API, slap some API into your software so that customers that ask for API have API. Otherwise, engineer an external Application Programming Interface into your systems.
"- API tokens are now stored only as hashes, which limits the impact of any similar incident."
WTF were they not already?
The number of systems that will show me the API token more than once makes me realize that many haven't figured out it is just a long password and should be treated exactly as such.
Except maybe using faster hashing, depending on usage
And you're absolutely right to push back on that.