7 ms·
Simple Ways to Protect an API
- vijayaggarwal 12y agoAccording 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 http://tools.ietf.org/html/rfc2617#section-4.4
- deleted 12y ago[deleted]
- EvanAnderson 12y agoThe main criticism relates to eavesdropping. Wrapping Basic or Digest authentication in TLS eliminates that issue.
- xorbyte 12y agoThe 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.
- ttharma 12y agoBoth 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.
- pan69 12y agoHTTPS 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..
- mobiuscog 12y agoWhy is the API accessible from the public internet if it's not a public API ?
- andreasklinger 12y agoWhy is an `/admin` area password protected if it's on the public internet?
- lsh123 12y agoIt 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.
- ttharma 12y agoAgreed, 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.
- lsh123 12y agoIf 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.