Simple Ways to Protect an API | Hacker News Reader

Simple Ways to Protect an API

techblog.thescore.com

17 pointsnwjsmith10 comments

It is not 100% clear but it looks like the authentication credentials in the blog post are static and are shared between clients (from the code comment: “In real applications, we will not have the authentication credentials lying around in code. We will store them in external configuration.”).

This is REALLY bad idea to have static and shared credentials. Especially in the case of mobile client when the client code itself is in a "hostile" environment. A "bad" guy can inspect the code and extract the authentication credentials. As soon as it happens, you need to update all other clients to push the new shared secret.

While OAuth protocol has a number of problems, it gets this right: all the tokens are specific to the client and the compromise of one token would not compromise others. The application can react by marking the compromised token as invalid on the server side without requiring expensive clients update.

Agreed, and theScore client apps actually use OAuth. We use HTTP Token Authentication for internal services with a limited number of consumers (other internal services). For this purpose, static and shared credentials are fine.

If this is an internal services call, then I am not sure what is the value of having HTTP authentication. Personally, I would setup X509 certificates on both client and server; and then just use those for the authentication. Plus IP restriction if you are hosting in the cloud.

According to RFC 2617[1], Both Digest and Basic Authentication are very much on the weak end of the security strength spectrum.

[1]: http://tools.ietf.org/html/rfc2617#section-4.4

The main criticism relates to eavesdropping. Wrapping Basic or Digest authentication in TLS eliminates that issue.

The article makes no mention of TLS anywhere, and the example endpoints are all HTTP. So, this is a thoroughly insecure implementation, relying on very weak security mechanisms, prone to straightforward interception and tampering, replay etc.

Both HTTP Basic and Token Authentication are secure when used over HTTPS. I updated the article to include a note about this as well as updated the code examples to use HTTPS.

HTTPS is only secure if no client credentials are stored on the client, e.g. hard coding a username/password pair in a mobile app. If a user needs to supply a username and password it would be OK I guess..

Why is the API accessible from the public internet if it's not a public API ?

Why is an `/admin` area password protected if it's on the public internet?

Reply on news.ycombinator.com