[deleted]
How not to write an API
121–130 of 172 posts
Re: How not to write an API
#122Well, 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
Re: How not to write an API
#123Whenever 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…
Did you make sure to feign forgetfulness and have them read it back to you?
Re: How not to write an API
#124Somebody 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.
I am surprised that this is the only comment mentioning SOAP.
I know that it'a a footnote to the insane brokenness of the rest of it, but ugh indeed. Anyone who remembered SOAP the first time around wouldn't re-invent it badly. Or at all.
Re: How not to write an API
#125In 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.
Re: How not to write an API
#126Earlier quoted context omitted.
Doesn't https take care of the same issue, though? And it doesn't solve the problem that if you're shipping an app the secret key can be found. So what does it solve?
You're correct - you shouldn't ship an app with a secret key embedded. That would be a flawed implementation. It's hard to be specific without knowing what you're doing. If you have an app that connects to a third party API like Twitter, that's one situation. If you have an API that other app developers will connect to - that's a second scenario. And third is if you have an API and you write your own app to connect t…
Even if your api uses oAuth I don't see how can you prevent the client app to steal the password.
At some point the user is going to have to give his password to someone. Can't the app ask the user for his password, keep it, and internally give it to oAuth to allow to use your api?
Re: How not to write an API
#127Re: How not to write an API
#128Earlier quoted context omitted.
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.
The ratings are public anyway.
Re: How not to write an API
#129Earlier quoted context omitted.
You can also include an extra random number in the hash, and require that within the window of acceptable timestamps the random numbers have to be unique. By the way, be aware than hash(string1 + string2) constructions are often vulnerable. hash(hash(string1) + string2) is better for most hashes, I believe. But you shouldn't roll these primitives yourself, either. Just use a proper library.
Do you have specifics on why strcat would be vulnerable? Or is it just because "abc"+"def" == "abcd" + "ef"?
[deleted]
Re: How not to write an API
#130How should an app utilizing an API send the API key so it can't be hijacked with tcpdump?