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.
How not to write an API
11–20 of 172 posts
Re: How not to write an API
#12Wait, 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?
Basically yes. As he did, he managed to get the API key by doing a TCP dump.
From there he was able to use the key to get the users and plaintext passwords. Very much wtf.
Re: How not to write an API
#13Somebody 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.
Re: How not to write an API
#14Despite 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.
It's a timebomb. If the company won't fix it then the problem gets worse and worse, waiting 4 years before setting it off is long enough.
Re: How not to write an API
#15I 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.
They've already screwed over their users to such a degree with this implementation that the only sane thing to do is to warn all of the user base to stop using it at once and never go back.
What's described in this article indicates a level of incompetence far beyond any hope of forgiveness by those users. If there was any reason at all to trust the API's designers, then what you describe would be the correct response, but this is very much a case where the only rational response is to tell everyone to leave immediately, forever. It's truly an unforgivable lapse of technical judgement.
It's not the way it is because of some honest mistake that someone made, like most security bugs are. This was by design, and it's bad enough that there's no reason to believe that the designers are capable of coming up with a better design.
EDIT: As others have pointed out, he did warn them. Even more WTF then!
Re: How not to write an API
#16Short 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.
I think you got a detail wrong.
I think that the app can only access all users registered with its api key. Same for passwords.
You say "all users registered on the site", the api says "Note, this can't be used to lookup just any user's password – the user must have been created by the API account."
Re: How not to write an API
#17Somebody 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.
Non-encrypted passwords are an artifact of legacy systems, and some modern businesses believe that the risk of plain-text passwords being leaked is lower than the risk of systems breaking due to updating passwords/authentication to an encrypted schema.
Some modern businesses don't make the best decisions.
Re: How not to write an API
#18-0.036264 Wait, did their API return a negative processing time?
The Math.abs is run client side.
Re: How not to write an API
#19Short 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.
I think you got a detail wrong. I think that the app can only access all users registered with its api key. Same for passwords. You say "all users registered on the site", the api says "Note, this can't be used to lookup just any user's password – the user must have been created by the API account."
Dammit, thanks, i corrected that.
Re: How not to write an API
#20I 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.
They've already screwed over their users to such a degree with this implementation that the only sane thing to do is to warn all of the user base to stop using it at once and never go back. What's described in this article indicates a level of incompetence far beyond any hope of forgiveness by those users. If there was any reason at all to trust the API's designers, then what you describe would be the correct respons…
I think saying that he "warned them" is a bit dishonest. He said the following as a side note 4 years ago:
I've just checked and you can obtain the password through an API call
after you register a new API user.