I'm developing some desktop software for a client to resell. The client wants to restrict the software so that the registration code will be specific to one and only one computer.
Besides using the MAC from the network card, does anyone have any other techniques (that work on both Windows and Mac OS X) for uniquely identifying a computer?
I'll play devil's advocate here and tell you that something like this probably isn't the best thing to discuss in "public".
With that said, look at what others may have done and possibly improve on (or take a portion of) it. MAC address, like you've said, is possibly okay to use. I've heard that Windows and other programs use hard drive information (serial number) -- according to this site, Windows Activation checks 10 different items and makes them into a unique key.
There used to be a serial number imprinted into the CPU's, as far as I have seen though; this information (PSN, Pentium Serial Number) has been deprecated. The information may possibly still exist, but at least in the P3 world it was gone. Also, I think the obvious choice of MAC address on the NIC for the main interface used for the host should be considered as a real possibility. Unless your client is not expecting ethernet interfaces to be present on the hosts that they sell to.
Another solution is to use a licensing technology with a dongle. This is a small device that plugs into USB or another I/O port on the host, and serves as a unique, physical key to activate the software.
A third solution is to provide a license manager. That is, when the software starts up, it queries a server on the network (either on the customer's LAN or else accessed at your company via the internet) that validates that the customer's usage of the software is legitimate. This is a good solution for "concurrent licenses" so customers can install your software on many hosts, but you license it for simultaneous use on a limited number of hosts. FLEXnet Publisher is an example of a license management solution.
The MAC address of the network card is the solution I used last time I worked for a company that licensed software to run on a specific host.
However, I want to offer a caution: if you do this type of licensing, you have to anticipate that it'll become an ongoing administrative chore to track your customers' licenses. Once you have a few hundred customers, you'll be amazed at how frequently you get phone calls with requests to change keys
"We upgraded our server to a gigabit network adapter, and now the license won't work because the new adapter has a different MAC address."
Or else the customers may replace their whole machine, and need an updated license to run your software on the new machine. We got these calls practically every day at the company I worked for.
You also need to trust the customer to stop using your software on the old computer (or network adapter) if you give them a new key. If you couldn't trust them to obey the license in the first place, how can you trust that they'll throw away the old key?
If you don't plan how you're going to support this administrative activity, don't license your product in this way. You'll only inconvenience your good customers, who would have cooperated anyway.
There is no sure way to uniquely identify a computer, if you assume a computer is built with many parts that can be replaced eventually.
Some hardware parts - MAC address, HDD disk serial number, even motherboard serial, etc - are a few good sources of "uniqueness" but as you may know if a client decides to upgrade the part the license depends on... be prepared for some customer support. Also to keep in mind is that some parts can be spoofed (the MAC being one of them).
An online license check is another good way to go - you can manage everything on the server side and even define your own rules for it (how many licenses per client/install, concurrency, etc) but the big thing to note is what happens when connection can't be established?
You might consider a third-party licensing utility which will more likely get this "right" and also provide you (or your client) with additional options should requirements change (and don't they always?). I'd mention some specific ones by name, but I'm really not intimately familiar them.
I would just use the MAC address to generate a request key, then require users to register with your client. Your client will have a special application that takes that request key and produces an activation key which the user can then use for activating the software. Once activated, the software works, just works - no occasionally phoning home for verification and such.
That's if it were a real requirement. My first task would be to try and convince the client that this was a bad idea.
The reason is that these schemes practically never prevent your code from being cracked. They do however make the lives of your genuine customers harder. I find it hard to think of any other industry that goes out of its way to annoy its genuine customers with schemes that never achieve their goals (other than government service, of course :-).
If you must do this, I'd just do a token effort to meet the contractual obligation (don't tell your client this however). Taking the MAC address (or a random number if, $DEITY forbid, the computer didn't have a network card) as the request key and using a program to just XOR it with an ASCII string to get the activation key, seems like a workable approach. I would also store both keys since you don't want the software to de-activate if they just change their network card (or even motherboard) - they still see that as the same computer and will not be happy if the software stops working.
Your code's going to be cracked regardless (unless the program is rubbish which I'm sure is not the case) - this method will give your genuine customers an avenue for moving their software to another machine if your client's company becomes unresponsive somehow (drops support, goes out of business, and so on).
The main trouble with all schemes that rely on the uniqueness of a bit of hardware is that the customer may choose to change that bit of hardware:
These can all be fixed by using those values to create a key at install time and only check against that key, not the changed value six months down the track. It means you have to store the request and activation values but upgrades will not require your users to go through the process of re-activating their software. Believe me, they will despise you for having to do that.