views:

95

answers:

3

Scenario:

A publically available Web Service that I have full control over. But I only want this specific desktop application (my published application) to have access to the Web Service. I could store a secret password in the desktop client, but that would be easy to crack.

Is there any known implementation that enforces this? PKI, assymmetric keys?

+1  A: 

WS-Security provides for X509 encryption.

Part of that implementation includes the possibility of only giving specific clients the generated public key. That way, only your selected clients can connect to the service.

Justin Niessner
+2  A: 

If the public will have access to copies of this Desktop App, any good reverser will be able to crack it and "imitate" its transactions with the server. It doens't matter how secure is your cryptography, everything you app needs to encrypt/decrypt data is included in the binaries, so the cracker only needs to dig it out of it.

The objective of cryptography is to protect data while it is being transfered, from "middle-man" hackers, but if you have access to anyone of the peers, you can easily crack it.

Your server must never trust what comes from the client side.

[edit resuming]

Despite you cannot 100% guarantee a supposed client to your server is or isn't your App or some "emulator" made by thirdies, you can complicate things to them. Its a common practice in game anti-cheats to sometimes, randomly, make the client App a trick question like "whats the hash of your main.exe from offset A to offset B?" or "from now on packet type 0x07 swaps with packet type 0x5f". Once a fake is detected, server enter in a "silly mode", act malfunctional, and blacklist their IP/account to this mode for several hours so they cannot have sure of what their program is doing wrong.

If you detect someone is building an emulator, make them start all over again: jumble the packet type tables, cryptography tables, change some packet formats and force your clients to update. You won't see crackers bothering you for a while... LOL

Havenard
One thing is encryption and a different thing is authentication. Public/private keys can be used to the effect of only accepting connections from clients having a (part of the) key.
Vinko Vrsalovic
So? The point stills.
Havenard
The key clients use to authenticate must not be embedded in the binary. So your point is only partially correct and irrelevant. You can distribute the client to the whole Internet, but the key to only a select few. Nothing in the binary will tell you how to connect successfully, it will only tell you you need a key.
Vinko Vrsalovic
Yes, the same as simply distributing accounts or registration keys that you can block anytime from using the service. This is a good idea indeed, but was not the question. He want that only his application (not his "authorized people") have access to the service.
Havenard
It's a bit interchangeable, all valid application instances have the key (ie, application owners are the authorized people). Although people can still steal the key, depending on the particular use case, a key might suffice.
Vinko Vrsalovic
A: 

The easiest way is message security using client and server certificates. The best way is to import the client certs in your server machines and hard code the client cert thumbprint in the app.config file. The other way is negotiation of certs which I haven't tried before.

If you are using IIS to host the service then client certificates using SSL is another option.

MSDN link on WCF Security.

Pratik