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.
How not to write an API
21–30 of 172 posts
Re: How not to write an API
#22Short 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.
Correction: an API account can see all users that registered through the API with that account's key.
Still, WTF!?
Re: How not to write an API
#23Short 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.
Correction: an API account can see all users that registered through the API with that account's key.
Still, WTF!?
Re: How not to write an API
#24Short 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."
However, the API key for any app can be discovered with zero effort, because it's included in each request. So you can retrieve the plaintext passwords for any user who has signed up with any app using the API.
Whoever created this monstrosity should be ashamed of themselves.
Re: How not to write an API
#25Earlier quoted context omitted.
He claims to have notified Criticker in 2010, and links to a post on their forum (username teario): http://www.criticker.com/forum/viewtopic.php?f=8&t=2063#p188...
Thanks for that, I skipped over that paragraph.
I don't think his post was blatant enough for the devs to pick up on it. Seems like the only guy that responded tl;dr'd it. He should have stated very clearly that this is a MAJOR security issue.
Re: How not to write an API
#26If 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.
Re: How not to write an API
#27Somebody 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.
> Non-encrypted passwords are an artifact of legacy systems
The copyright is from 2004, that's only 10 years ago. I wouldn't say plaintext passwords were a sensible decision back then.
> Some modern businesses don't make the best decisions.
Some modern businesses don't have the best priorities.
Re: How not to write an API
#28It 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.
Re: How not to write an API
#29Somebody 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.
"Who the hell thinks it's OK to store non-encrypted passwords in this day and age?"
You'd be surprised: http://plaintextoffenders.com/
...and an amazing number of finance organisations who can't handle non alpha-numeric characters in passwords, indicating failure to hash.
Re: How not to write an API
#30Short 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 dont think you realize how common the WTFs in this situation are. If you are dealing with a reputable company, this is super super WTF.
When you are looking at a small website/API someone made for fun or something....It can normally be badly broken in less than 2-3 minutes....and I'm not even that talented like some of the guys out there.