Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How not to write an API

ghost.teario.com

Post reply on HN
Print view View original

41–50 of 172 posts

Re: How not to write an API

#41

Post by makaveli8 »

digitalpacman wrote: post #34

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 e…

The problem is that the app uses the same API key no matter what device it is installed on. If you download the app today you can find the API key and use it to retrieve the passwords for any users that have signed up to Criticker using the app - just as the author has done.

Re: How not to write an API

#42

Post by choult »

bm1362 wrote: post #39
philjackson wrote: post #11

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.

It's not particularly sensitive data being jeopardized- isn't it just movie reviews?

Given the prevalence of password reuse, exposing user passwords is never a good idea.

Re: How not to write an API

#43

Post by vrybas1 »

mercurial wrote: post #27
minimaxir wrote: post #17

Earlier quoted context omitted.

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.

↑ This!

Re: How not to write an API

#44

Post by makaveli8 »

CatMtKing wrote: post #25
LukeB_UK wrote: post #9

Earlier quoted context omitted.

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.

Agreed - He didn't even say that it was an issue at all. He seemed more concerned that the users are scoped to particular API keys and that he will lose his reviews.

Re: How not to write an API

#45

Post by iconjack »

rdegges wrote: post #26

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…

Does Stormpath have a painless way to extract user data? I worry about lock-in.

Re: How not to write an API

#46

Post by makaveli8 »

icebraining wrote: post #36
mwfunk wrote: post #15

Earlier quoted context omitted.

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…

Not trying to excuse Criticker, but from my POV as a user, this isn't exactly Mt.Gox or a bank; it's a website to rate movies, and all the information you put there is already public. All someone can do with my password is rate movies on my behalf. Again, this doesn't excuse them, especially since we all know people reuse passwords. I'm just saying that the site is useful even if you know everyone can get in.

A lot of people reuse passwords across multiple sites - so nab their plain-text password + find out their email address, and you likely able to log into various other services using their credentials.

Re: How not to write an API

#47

Post by martypitt »

scoot wrote: post #29
mercurial wrote: post #13

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.

" 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.

I was astonished to discover about 18mths ago that MelbourneIT, Australia's largest Domain Registrar stores their users passwords in plain text, and display them to the customer service reps during calls.

I discovered this when on a phone call, the agent asked me what my password was, and when I refused to tell him (but offered any other aspect of my account for identity), it took a lot of convincing to get the rep to serve me. If I were malicious, I could speculate that a little social engineering may have gotten the employee to give me the password.

EDIT : To clarify, it was a comment the rep made about my password indicated that he could see my password in clear text on his screen. I asked him, and he confirmed this.

I tweeted the CTO [1], who advised me they were working on the problem, but it was still several months away from being resolved.

This level of insecurity from a major IT service provider was both shocking, and inexcusable in my humble opinion.

[1] https://twitter.com/marty_pitt/status/223622794490019843

Re: How not to write an API

#48

Post by theboss »

Mithaldu wrote: post #40
theboss wrote: post #30

Earlier quoted context omitted.

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.

My day job is web developer and i sit in an IRC channel where roughly half the traffic is making fun of security issues of sites. Such a glorious combination of fuckups doesn't come about that often. I'm honestly more apalled that the passwords are in plaintext than that they expose them like that. I cannot say i am surprised though. A general amount of carelessness, undeserved self-confidence and ignorance is a give…

I'm not sure I agree with ``carelessness, undeserved self-confidence'' but I definitely agree with ignorance.

I think the best thing is that people writing code just don't understand the internals of how a lot of web attacks work and why the best practices for security prevent them.

I reported two account hijack vulnerabilities on startups this weekend and was met with ``What is CSRF?''.

I think the reason for this is security people keep to themselves and work as consultants. Instead of making my own company, I can go around finding people who need what I know and get easy low-risk money.

Also, there really is no place to hire a ``security person'' at a early stage startup. If a security guy DOES get hired, it's either part of an IR team, an internal pentest team, and if this is the case then there's already way too much code written to even check it for the most basic best practices (you might use some tool for static analysis but are you really going to check out the thousands of issues?)

I don't like bashing PHP, because I think it is actually a phenomenal language for people who know what they are doing, but it is definitely a security death-trap for those who don't.

Re: How not to write an API

#49

Post by rdegges »

iconjack wrote: post #45
rdegges wrote: post #26

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…

Does Stormpath have a painless way to extract user data? I worry about lock-in.

Yah -- you can use the API to export stuff really easily. We also have export scripts and stuff.

Furthermore, we'll go out of our way to help you move off the platform if you want.

Re: How not to write an API

#50

Post by danielharan »

bm1362 wrote: post #39
philjackson wrote: post #11

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.

It's not particularly sensitive data being jeopardized- isn't it just movie reviews?

Besides choult's point, users can often be de-anonymized based on just a few ratings. Someone did this by cross-referencing dates in the Netflix data set and those available on one of the bigger sites.

Suddenly the fact that you were watching documentaries or movies that let you infer their political or sexual proclivities could be determined by outsiders.

Post reply on HN