Whenever I get that plaintext password "vibe" on a site, I like to make my password something somewhat degrading go the site; like "thisSiteSux!", but slightly more vulgar. It's not my fault if they see it.
Once after having gotten the vibe, I ended up on phone support with the site in question. At some point I was instructed to "log back in with ummmm that uhhh same password you signed up with...." I could tell that my plaintext-dar hadn't failed me that time :)
Could someone with a solid security background provide a example of how to properly handle the issues that this API fails so badly at?
While some developers may be able to clearly identify bad practices, best practices may not always be so clear.
I'd love to know what a best practice would be for things like authentication to an API and some of the other issues brought up here.
Somebody is trying to outshine Mt. Gox in terms of amateurism. I wouldn't be surprised to find a number of other vulnerabilities (SQL injection ?). Who the hell thinks it's OK to store non-encrypted passwords in this day and age? It's not like you don't have a major security breach every month...
Also, I like the 'handler.php' endpoint returning some kind of ugly pseudo-SOAP. Ugh.
It seems to me, that many companies think, that computer science is just plainly simple. You can just put any task to a new bachelor or even student that claims he can program.
I learned the hard way, that even the creation of internal APIs of software is hard, since you can make many errors. I made many errors, after I came from university. After I made them, I knew it better, because I had to manage an other developer that had to use it and I saw what a mess it was.
External APIs are even more difficult to create, because such things as security and others have to be covered ... but still it seems many companies thing any stuff scribbled by a student in the first semester would suffice.
I don't care if this comes off as trolling, but here it is: as I read through this, I thought to myself, much like the author, "how appaling!" - then I saw the word "PHP" - and went "oh, well, that figures".
<RequestProcessingTime>-0.036264</RequestProcessingTime>
Wait, did their API return a negative processing time?
It's a felony in the US to do what the author did here, right? Not that there's any indication where they're from, I'm just curious.
Despite the warning to the company back in 2010, I'm not sure he should be publishing this. He's putting the 2000-odd users at risk by teaching us how to get their passwords and usernames like that, it's even worse if we can get at email addresses too. I would bet the majority of those registered reuse the passwords.
Well, it seems they took the entire API down in response:
Due to a security breach, the Criticker APIs have been taken off-line for an unspecified amount of time.
We apologize for the inconvenience.
And here I was, looking forward to actually verifying if this stuff was true...
Wait, just to be clear - so anyone who downloads this app can trivially retrieve the username and password for all 2000+ users of the app? Did I misunderstand the article?
From http://api.criticker.com/
> Due to a security breach, the Criticker APIs have been taken off-line for an unspecified amount of time.
> We apologize for the inconvenience.
What the, why? Who thought this matched any sane API authentication pattern?
It give me chills when i read this quote:
Returns the password for a user associated with the API account. Note, this can't be used to lookup just any user's password – the user must have been created by the API account.
If anyone from the Criticker team is here on HN, I'd be happy to help you guys get this resolved -- my company Stormpath (https://stormpath.com/) provides a really secure way to handle user accounts.
I'll help you guys integrate, or -- if you prefer, I'd be more than happy to dive into your source and help figure out problems and get them resolved. We have a pretty huge team of security experts, and we're all more than happy to help.
I'm randall@stormpath.com if you'd like to chat.
In case anyone is wondering, there are ways to use API keys securely, i.e. without sending them in plaintext on each request.
One common way is OAuth signed requests: http://hueniverse.com/2008/10/beginners-guide-to-oauth-part-... There should be an OAuth library for the language that you are using.
I hope that the author notified Criticker about these issues before putting them out there on the internet. Not doing so would be extremely irresponsible and is sort of screwing over the users of Cricketer.
Well, bad APIs and security is the norm, unfortunately. As example DigitalOcean doesn't use signatures, and uses static API key. Would you consider that to be secure? Especially if we aknowledge all the weakness of SSL/TLS/HTTPS. https://plus.google.com/+SamiLehtinen/posts/1qFhf9fAbU6
Raw password storage is more common than we like to believe. A simple way for webapps to communicate that raw passwords are not being stored would be convenient. A small 'NORAWPW' image in the footer perhaps. it would ease my worries, especially with cryptocurrency related webapps.
Despite all the plaintext password nonsense, I still can't wrap my head around the fact that there is an API call for getting passwords. What legitimate use could it possibly be?
Wow... storing passwords in plain text? Even worse, non-encrypted data transport and client accessible credentials? Those "programmers" should be shot!
My opinion is that any company building an API should run at least one bug bounty on it before releasing it to the public.
I'm not sure what is worse, the bad API/app design, or the blog post publicly sharing how to abuse it...
I am waiting for an API for a specifically designed API-maker software named "Yo dawg".
How should an app utilizing an API send the API key so it can't be hijacked with tcpdump?
Someone please change the title to "How not to disclose a vulnerability"
Look also about howto write good API:
http://theamiableapi.com/2012/01/16/java-api-design-checklis...
found that nice article in:
http://stackoverflow.com/questions/10323622/java-api-design-...
Raw password storage is more common than we like to believe. A simple way for webapps to communicate that raw passwords are not being stored would be convenient. A small 'NORAWPW' image in the footer perhaps. it would ease my worries, especially with cryptocurrency related webapps.
To those of your interested on the topic, leanpub has an ebook you can get for free here:
This post is more about security than just APIs... dislike title. Also.. I don't see how this is an issue. If the user signs up via your app... and you wanted their password. You have it. Sure it's a big deal if someone steals your key... but if you always do it over SSL, they have to steal the "phone" or the "app" that you use. And if they steal the phone... they can use things like "email reset password", because email will most likely be logged in anyway.
Short version: http://criticker.com sells access to their API for apps. Any API account can retrieve a list of all users it registered on the site, then retrieve the cleartext password for each user it created.
There are so many WTFs in this whole situation that it's a wonder criticker has managed to keep the website online. Which is a shame, as it looks like a really useful website.