CODEWITHSUNDEEP
phpapisecurityapi-key
Sam
Sam

Reputation: 5526

Using an API Key System

I would like to implement an API key system to secure API calls to my app.

The way I think will work is my having a private key/secret per account. Each request contains the time, account id and a hash(time+secret).
The server can then do the same thing with the users secret from the database and check that against the hash the client sent.

Is this a reasonable way to do it? It is open to a brute force attack, but I'm thinking that as long as the secret is long (ie uuid) it shouldn't be too much of a problem...

A Thought

Any one could submit another request with the same time and hash and have it accepted, after all its valid, right?

Upvotes: 1

Views: 2590

Answers (3)

Peter O.
Peter O.

Reputation: 32878

For APIs that only retrieve data (other than private data), rather than create, modify, or delete data, option 1 in this answer may be adequate. See, for example, the Bing Maps REST API and Google Maps Premier web services (where here, Google Maps also hashes the URL with a digital signature and a special key known only to the API user, which, while providing protection against modifying the URL, apparently still doesn't provide replay attack protection).

In fact, some APIs that retrieve data do not use an API key, but rather limit access in other ways (for example, the YouTube API allows retrieving publicly available data on videos and users' channels without requiring authentication, but limits the number of recent requests).

Options 2 and/or 3 are required for APIs that do more than just retrieve publicly-available data, for instance, if it modifies user profiles, posts content, or accesses private information: see for example, the YouTube data API authentication page, where OAuth is mentioned as one possible authentication scheme.

Especially for option 1, the API key here is used in order to track access by users to your API, and most importantly, limit access by those users. Option 1 may not be appropriate for APIs that allow unlimited data access.

(This is an answer since it's too long to be a comment.)

Upvotes: 2

rsj
rsj

Reputation: 788

The problem being that the nonce + hash can be replayed. A real authentication protocol requires at least two messages:

Server                Client

    ---->challenge --->
    <----response------

For example, the challenge could be the nonce, supplied by the server, and the client's response would be the hash of password with the nonce.

Unfortunately, this requires state, and the whole problem with RESTful protocols is that they do not want the hassle of keeping state. And yet they want to authenticate...

So you really have three options:

Option 1: Pretend the problem does not exist, and use the stateless "authentication" protocol. This is no different from using a cookie. The nonce + password-hash is no more secure than a cookie. Cookies can be stolen, etc, and replayed. The entire web is now plagued by these replay attacks.

Option 2: Try to bolt an authentication protocol onto a stateless communication method. Here, you would have the client send you a UTC time-stamp instead of a nonce. The use of the time-stamp provides limited defense against replay. Obviously your clock is not going to be synched with that of the client, so your server will allow any timestamp within some error margin, and that error margin will be the replay margin of the authentication protocol. Note that this violates REST, because the authentication message is not idempotent. Idempotent implies "can be successfully replayed by an attacker".

Option 3: Do not try to bolt an authentication protocol onto a stateless protocol. Use SSL. Use client certificates. Instead of having the client download a string, let them generate a certificate, or you can supply them with a key-pair. They authenticate via SSL and do not authenticate in your REST layer. SSL has lots of "overhead". It is not lightweight, precisely because it does address these replay issues.

So at the end of the day, it depends on how much you value access to your APIs.

Upvotes: 4

matthiasmullie
matthiasmullie

Reputation: 2083

Server contains:

  • username
  • password hash

Client sends:

  • username
  • random string
  • hash of (password hash + random string)

When clients calls server, server creates hash of password hash (which it knows itself) + random string (given in GET by calling client) eand evaluates if that matches the hash (given in GET by calling client)

Even better would be to create 1 function that generates a secret hash from (password hash + nonce) where "nonce" (something random) is also stored on server. Then make it possible to call the server once with username + password, which returns the secret hash; then have subsequent calls solely depend on username + random string + hash of (secret hash + random string) with the same methodology as described above, but secret being what was then password. This way, even if your secret would be intercepted and reversed, your pass would still be safe.

And obviously, good hashing algorithms: no rot13 and even solely md5 is questionable.

Upvotes: 0

Related Questions