Binding security token to particular client machine

Question

There are some applications in Silverlight 3 and WPF which communicate with data web services (based on WCF). It is necessary to protect data web services. Only known users should have access to the data. Solution will work in local network without access from outside.

Client connects first to authentication web service (providing user name and password) via SSL and obtain Security Token. Afterward this token is passed to data web services to validate user and get access to the data.

Here is question: how to limit usage of Security Token to the machine for which it was initially issued?

Initial idea is to include into the Security Token client IP address but it can cause re-authentication in some cases. For example when user machine has local network and wi-fi network connections. In this case switching from one connection to another will cause changing IP address of client machine and as result Security Token will became invalid.

Are there any patterns for doing this sort of thing?

Answer 1

If the clients can have system access, try to read the hard drive serial number, network card mac address, mainboard serial number etc., combine them together and generate a hash out of it. Then send this hash along with the credentials to obtain the security token. The hash should be saved on the server as well. Then on all subsequent requests a client submits the security token along with the just generated machine hash. The server validates both credentials and the hash. In particular, whether the security token was generated using this particular hash.

Some amount of work, but it's doable and it's fun.

Answer 2

There's no 100% way to bind a security token to a machine :(

What we typically do is assume that if you've got the credentials to get the token in the first place, you're on the good team and we kinda trust you. After all, we're letting you access our data anyway.

I have a couple of thoughts:

• For your tokens, you probably want to use Forms Authentication. By default, it will issue tokens as cookies, but that can be configured. Another cool thing is that it will auto-expire (again, configurable) the tokens. There are a lot of potential mistakes to make with your own tokens/security system and using an existing system will give you quite a leg up. There's even a WCF service for authentication.
• If you're really, really serious about limiting calls from specific machines, you can use 2 way SSL with certs on the client machine. It's still not a foolproof solution (somebody on the good team could still share the certs with somebody on the bad team), but it makes sure that the client has a cert that you distributed. The downside is that this stuff is a pain in the neck to configure.

---

Clarification: Try a thought experiment. Even if you could call the Win32 APIs from Silverlight to get machine info and use that for the token, you still don't have a foolproof solution. Your API calls could be virtualized. For that matter, your entire client machine could be virtualized. For the proof of this, see the Darknet paper or any DRM system in existence. This is not winnable.

Here's how you can limit the damage of somebody from the good team giving somebody on the bad team your token. You expire the tokens after a certain amount of time. Then the scenario you're dealing with is this: A user provides a legit user/pass and so they have access for a certain amount of time (10 minutes, 10 hours, 10 days, whatever), and you don't care whether they're calling from Silverlight, AJAX, or an Atari 2600. After all, they just proved they were on the good team with the user/pass. This is a game you can win.