How should an app utilizing an API send the API key so it can't be hijacked with tcpdump?
By using HTTPS/SSL. But the onus of that is on the API provider...
How not to write an API
131–140 of 172 posts
Re: How not to write an API
#132Earlier quoted context omitted.
I think your efforts on #1 are moot because I don't think there's a way to include the API key in a mobile app such that it can be used by the app but not extracted by an attacker.
#1 is a fairly standard security concept used by protocols like oAuth or JWT. It requires an API key pair (public and secret key). The secret key is only used for signing and is never passed in the request. Used in combination with nonces and time stamps you can make a secure API that isn't susceptible to replay attacks.
Even if it's not passed in the request it's still in the app so isn't it vulnerable to reverse-engineering?
Re: How not to write an API
#133Well, it seems they took the entire API down in response: http://api.criticker.com/ Due to a security breach, the Criticker APIs have been taken off-line for an unspecified amount of time. We apologize for the inconvenience. And here I was, looking forward to actually verifying if this stuff was true...
[deleted]
Re: How not to write an API
#134Earlier quoted context omitted.
I think you got a detail wrong. I think that the app can only access all users registered with its api key. Same for passwords. You say "all users registered on the site", the api says "Note, this can't be used to lookup just any user's password – the user must have been created by the API account."
However, the API key for any app can be discovered with zero effort, because it's included in each request. So you can retrieve the plaintext passwords for any user who has signed up with any app using the API . Whoever created this monstrosity should be ashamed of themselves.
To reiterate: Any user of an app can look at the passwords of any user created with that app.
Re: How not to write an API
#135Earlier quoted context omitted.
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?
The user will enter their password on the provider's site via the phone browser. It relies on the user's trust of the system browser.
Re: How not to write an API
#136Wow... storing passwords in plain text? Even worse, non-encrypted data transport and client accessible credentials? Those "programmers" should be shot!
If we started killing people for making mistakes, none of us would be alive.
Re: How not to write an API
#137Someone please change the title to "How not to disclose a vulnerability"
Re: How not to write an API
#138Despite all the plaintext password nonsense, I still can't wrap my head around the fact that there is an API call for getting passwords. What legitimate use could it possibly be?
Re: How not to write an API
#139Could someone with a solid security background provide a example of how to properly handle the issues that this API fails so badly at? While some developers may be able to clearly identify bad practices, best practices may not always be so clear. I'd love to know what a best practice would be for things like authentication to an API and some of the other issues brought up here.
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 as their transport protocol we probably wouldn't even be having this discussion.
There's a ton of other security measures/protocols that should be taken and followed, most of which are already talked about in other parts of these comment threads. I just wanted to really point out that what you're describing above sounds an awful lot like an HMAC code.
[1] http://en.wikipedia.org/wiki/Hash-based_message_authenticati...
Re: How not to write an API
#140Earlier 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…
Sorry for being harsh, but your "solutions" are mostly useless in the context of providing an API for phone apps. Use OAuth or similar and make sure every user has their own account. That's the only answer. Don't roll your own! Especially don't roll your own when you don't have a solid security background. You have obviously heard some of the right terms, but how and where you can apply them is at least as important…
When it comes to API security, you can't be too harsh! I guess I was trying to explain it more conceptually, since it sounded like the person asking didn't understand the concepts.
But I stopped short on #1, as your post points out. You're absolutely right when it comes to designing an API for consumption by apps that will be distributed as packages.
I can't update my original post with a clarification, so here's what the end of #1 should have said:
1 (continued)
If either the clients' source or compiled code can be inspected by attackers (which is true for distributed, i.e. native mobile or desktop, apps), you don't want to make client app developers include their secret authentication key directly in their app. In this case, consider using OAuth 2.0 for authentication instead.
With OAuth, the client app has the user authenticate with their own credentials, where the API will respond with a per-user access token (that can easily be revoked per user if necessary), which the client app will then use for subsequent authorized requests.