How not to write an API • Hacker News Board

Re: How not to write an API

#141

Post by JangoSteve » Mon, Mar 10, 2014, 1:45 PM UTC

jrub wrote: post #139

JangoSteve wrote: post #81

Earlier quoted context omitted.

I wouldn't say I have a solid security background, but there are four best-practices I can think of that would have prevented the security vulnerabilities outlined by this post: 1. Hash the secret API token/key given to each client that is sent to the server with each API request. This will prevent attackers from being able to find out your secret token. If you only hash the secret token though, this still won't help…

I think you're describing an HMAC[1] authentication code here. Certainly signing your requests as actually having come from your application is a legitimate means of security. But there are much lower hanging fruit (in terms of available security measures). Specifically, using SSL to handle API traffic. That should absolutely always be step 0. In instance of this specific post, had the API provider enforced using SSL…

You're correct; if you see my reply here [1], you'll notice I mentioned it by name.

See #2 in my original response concerning SSL. And notice the difference in length and complexity between #2 and #1; it was written this way intentionally to highlight the complexity of doing security authentication properly, in order to encourage the use of SSL, given that it is both more "full-proof" and simpler.

[1] https://news.ycombinator.com/item?id=7371259

EDIT: Please also see the point @Rizz pointed out, in that you'd still want to use something like OAuth, since HTTPS doesn't solve the issue of an attacker knowing your client's API key by inspecting its distributed code.

Re: How not to write an API

#142

Post by [deleted] » Mon, Mar 10, 2014, 1:49 PM UTC

woah wrote: post #98

JangoSteve wrote: post #81

Earlier quoted context omitted.

I wouldn't say I have a solid security background, but there are four best-practices I can think of that would have prevented the security vulnerabilities outlined by this post: 1. Hash the secret API token/key given to each client that is sent to the server with each API request. This will prevent attackers from being able to find out your secret token. If you only hash the secret token though, this still won't help…

What's the advantage of using your hand-rolled hashing scheme instead of just https?

[deleted]

Re: How not to write an API

#143

Post by JangoSteve » Mon, Mar 10, 2014, 1:51 PM UTC

woah wrote: post #98

JangoSteve wrote: post #81

Earlier quoted context omitted.

I wouldn't say I have a solid security background, but there are four best-practices I can think of that would have prevented the security vulnerabilities outlined by this post: 1. Hash the secret API token/key given to each client that is sent to the server with each API request. This will prevent attackers from being able to find out your secret token. If you only hash the secret token though, this still won't help…

What's the advantage of using your hand-rolled hashing scheme instead of just https?

There's not really any advantage as far as I know. In fact, as I stated in my explanation, using HTTPS is more full-proof. So why wouldn't you do that instead?! That's the point.

If I had to think of an advantage though, it'd be for the sake of any developer who needs to design their first API, and is inspired by yours. If you just used #2 then with plain-text authentication, and a developer copies your API without using SSL, then they'll have a horrible security problem. If you used #1 as well, then they'll still have an okay API, it just won't be suitable for use by packaged/distributed client apps.

In fact, this is purely conjecture, but that could be what happened here in the case of criticker. Who knows?

Re: How not to write an API

#144

Post by dancecodes » Mon, Mar 10, 2014, 1:58 PM UTC

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

Re: How not to write an API

#145

Post by pushrax » Mon, Mar 10, 2014, 2:41 PM UTC

camus2 wrote: post #78

jimlei wrote: post #67

Earlier quoted context omitted.

You mean like Symfony, Laravel, etc? Frameworks that a lot of PHP developers use these days...

You dont need a framework to do PHP webdev, in every other languages,you do.That's my point, PHP IS a templating language,no Symfony,Zend or Laravel can change that. If i write "print" in Python it wont output the result back to HTTP like PHP does. Ruby or Java dont have <?ruby or <?java tags, you get my point.

Well, many Ruby webapps use erb, which is basically the same thing.

Re: How not to write an API

#146

Post by pushrax » Mon, Mar 10, 2014, 2:41 PM UTC

camus2 wrote: post #78

jimlei wrote: post #67

Earlier quoted context omitted.

You mean like Symfony, Laravel, etc? Frameworks that a lot of PHP developers use these days...

You dont need a framework to do PHP webdev, in every other languages,you do.That's my point, PHP IS a templating language,no Symfony,Zend or Laravel can change that. If i write "print" in Python it wont output the result back to HTTP like PHP does. Ruby or Java dont have <?ruby or <?java tags, you get my point.

Well, many Ruby webapps use erb, which is basically the same thing.

Re: How not to write an API

#147

Post by tyrick » Mon, Mar 10, 2014, 2:46 PM UTC

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.

Re: How not to write an API

#148

Post by tyrick » Mon, Mar 10, 2014, 2:46 PM UTC

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.

Re: How not to write an API

#149

Post by jcromartie » Mon, Mar 10, 2014, 2:55 PM UTC

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.

> finance organisations who can't handle non alpha-numeric characters in passwords, indicating failure to hash

When I see this kind of limitation, I usually assume that they have some old mainframe with a fixed-width 7-bit password field, that would take an enormous engineering effort to change or replace.

Re: How not to write an API

#150

Post by jcromartie » Mon, Mar 10, 2014, 2:57 PM UTC

SideburnsOfDoom wrote: post #125

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.

Ways like HTTPS?