views:

40

answers:

3

I'm fleshing out an idea for a web service that will only allow requests from desktop applications (and desktop applications only) that have been registered with it. I can't really use a "secret key" for authentication because it would be really easy to discover and the applications that use the API would be deployed to many different machines that aren't controlled by the account holder.

How can I uniquely identify an application in a cross-platform way that doesn't make it incredibly easy for anyone to impersonate it?

A: 

Encrypt it (the secret key), hard-code it, and then obfuscate the program. Use HTTPS for the web-service, so that it is not caught by network sniffers.

Bozho
+1  A: 

You can't. As long as you put information in an uncontrolled place, you have to assume that information will be disseminated. Encryption doesn't really apply, because the only encryption-based approaches involve keeping a key on the client side.

The only real solution is to put the value of the service in the service itself, and make the desktop client be a low-value way to access that service. MMORPGs do this: you can download the games for free, but you need to sign up to play. The value is in the service, and the ability to connect to the service is controlled by the service (it authenticates players when they first connect).

Or, you just make it too much of a pain to break the security. For example, by putting a credential check at the start and end of every single method. And, because eventually someone will create a binary that patches out all of those checks, loading pieces of the application from the server. With credentials and timestamp checks in place, and using a different memory layout for each download.


You comment proposes a much simpler scenario. Companies have a much stronger incentive to protect access to the service, and there will be legal agreements in effect regarding your liability if they fail to protect access.

The simplest approach is what Amazon does: provide a secret key, and require all clients to encrypt with that secret key. Yes, rogue employees within those companies can walk away with the secret. So you give the company the option (or maybe require them) to change the key on a regular basis. Perhaps daily.

You can enhance that with an IP check on all accesses: each customer will provide you with a set of valid IP addresses. If someone walks out with the desktop software, they still can't use it.

Or, you can require that your service be proxied by the company. This is particularly useful if the service is only accessed from inside the corporate firewall.

kdgregory
That's the thing. It's not MY desktop app. My web service exposes functionality to companies that wish to use it in their own desktop apps. I just want to make it impossible for someone to submit fake data to those companies' accounts.
David Brown
Well, give them credentials, and if they compromise the credentials - their problem.
Bozho
A: 

Generate the key using hardware speciffic IDs - processor ID, MAC Address, etc. Think of a deterministic GUID.

You can then encrypt it and send it over the wire.

Ryan Michela