Identify client based on computed hash

Question

I'm currently developing a web application which will serve data to iPhone clients. In order to be the owner of the data, I don't want other clients to be able to get it.

I thought I could use a shared secret key between the server and the clients : a hard-coded string that would salt the timestamp to ensure that the request has been done by one of my clients. So the request would look like this :

http://domain.com/request/[desired_object_id]/[device_id]/[timestamp]/[hash]

I would compute the hash like this in the app :

hash = sha(desired_object_id + device_id + timetsamp + "mysecretkey")

And on the server side, I'd just ensure that the hash was properly generated before sending the data. (all objects identified by "desired_object_id" are available to all the subscribers). As an alternative, I could also generate a random key rather than a timestamp.

The issue is that it doesn't sound secure to me... The data is not critical, it's just that I don't want to offer a public API used by non-subscribers. And doing this would also prevent me from changing the secret key, because this would force the users to update to a new client version (not very good for business...)

Is there any other known issue with this ? Is there a better way to do it ? Preferably with the same simplicity.

Answer 1

Multiple problems here:

1. This setup would force putting the secret key on the client. Anyone with decent reverse engineering skill could retrieve it, and then they reproduce all requests at will.
2. There's no point of putting things like 'desired_object_id and such in the hash, if all these pieces are visible in cleartext (the URL). The only reason to do this is preventing the attacker from finding your secret key. But the easier prevention method here is to just simply pick a good (high entropy) secret.
3. Timestamp is the weakest form of a nonce. If you need to reproduce the timestamp on the server end, then you are forcing all the clients to have well synchronized clocks. If you're using it merely for a nonce, then you're failing to recognize an important property of nonces: they have to be random. Timestamps aren't random, even if the clocks are sloppy, they're going to be within a day (86400 secs per day), out of the possible 32bit (4.2 BILLION seconds), which is utilising a tiny fraction of the possible keyspace, and it's not even randomly spaced, they're clumped all together around a value you pretty much know (current time).

Answer 2

I found an interesting article on stackoverflow, which describes different ways of doing this.

Answer 3

First things first: your "hardcoded string" cannot be secret, because every client instance contains it, an easy prey for reverse engineering. The attacker already has it. A famous example is the encryption key for DVD contents, embedded in some "authorized" software players like PowerDVD...

So what you are looking for must be a per client secret string -- which can be a password, or a value stored in a cookie on the client.

Then the easy answer: use SSL (i.e. HTTPS). Within the request, embed the per-client secret string (this will occur automatically with a cookie); SSL handles the rest. In particular, SSL will protect not only the request but also the data itself from the prying eyes of eavesdropper. You will not get anything comparable in terms of security out of any home grown scheme, regardless of how many hash functions and time stamps you include in the stew.