API Key question - Snooping key out of a request

[TechBoyJK]

Many web services that provide service via an API provide their authorized users an API Key to submit along with their requests.

I'm trying to understand the basic methodology and some of the security implications.

1) User requests API Key
2) User granted API Key
3) User requests resource, affixes APIKey to request
4) Service checks API key, grants request


My biggest question is in instances where you are creating ajax/jquery type requests to a web service, and you have to include your API Key. It'll be right there in the browser with the rest of the request details.

Or am I missing something? Is there a way to obscure the api key? What is to keep someone from snooping that key out of the request and using it for their own requests?

 

[Ken g6]

You're not missing much. That's why many people strongly encourage using HTTPS to secure such web services.

 

[TechBoyJK]

You're not missing much. That's why many people strongly encourage using HTTPS to secure such web services.

Even if using https, which would help prevent man in the middle type snooping, can't the end user still pull the apikey out of the browser dataset?

ie.. I go to facebook.com. Facebook has a jquery script that sends a get request to a 3rd party API. If I pull up developer console in my browser, I can see all those requests going out. Couldn't I potentially get Facebook's apikey to that webservice and start using the webservice using facebook's key?

 

[Ken g6]

Um...yes? You can also fake browser calls with something like cURL, or just automate your browser with something like Selenium.

What is it about this scenario that you think is a security risk and you are trying to prevent?

Couldn't I potentially get Facebook's apikey to that webservice and start using the webservice using facebook's key?

Did you think the apikey is one key that a service, e.g. Facebook, has and hands out to everyone? They generate unique keys for each user, provide them only with the correct password, and they usually expire after a few minutes or hours.

 

[DaveSimmons]

This works better if one or more of the key(s) are used as secrets and you send a hash instead of the secret itself:

For example:

GetListOfMatches( search string, api-user-id, UTC-time, hash )

Where hash is something like md5( string + UTC-time + api-secret )

Ideally the api-secret is not embedded in your code, it is either fetched by the client at startup, or the client connects to your own server to ask it to generate hashes as needed.

Edit: or this:

Did you think the apikey is one key that a service, e.g. Facebook, has and hands out to everyone? They generate unique keys for each user, provide them only with the correct password, and they usually expire after a few minutes or hours.

 

[Mark R]

Or am I missing something? Is there a way to obscure the api key? What is to keep someone from snooping that key out of the request and using it for their own requests?

You have 2 options:

1. Use HTTPS - this encrypts the connection and prevents snooping of the API key.
2. Use the APIKey like a user name, and allocate a private key at the same time. An API request number and message signature (HMAC) is appended to each request and used to validate the request.

Option 2 is more useful where you have to prevent a "replay attack" where an unauthorised user sniffs a message, and then re-sends it at a later date in order to obtain unauthorised use.

 

[Crusty]

You have 2 options:

1. Use HTTPS - this encrypts the connection and prevents snooping of the API key.
2. Use the APIKey like a user name, and allocate a private key at the same time. An API request number and message signature (HMAC) is appended to each request and used to validate the request.

Option 2 is more useful where you have to prevent a "replay attack" where an unauthorised user sniffs a message, and then re-sends it at a later date in order to obtain unauthorised use.

Is there ever a scenario where you wouldn't want to prevent a replay attack?