Geeks With Blogs
Joaquin Jares Just another geek's blog

I was commissioned recently on making a Product Key system for a shrink wrap piece of software. And my first thought was: there must be some sort of best practice or pattern language for this. I mean, many people sell shrink wrap software every day, and inventing the procedure each time is just to costly and error probe. Turns out, I was wrong. There is no pattern or best practice for product keys (at least none that I could find in the internet, forums or books). It makes sense, though, for several reasons. First, the market for enterprise software is way bigger than the market for shrink wrap, and there’s where all the advise is directed to. Next, because product keys are something best kept secret. As we know, security by obscurity was never a great idea, so let me share what I have come up with.

Before I start, let me tell you Joel has it right, twice: he says that product keys aren’t a good measure of security (at least I think it was him, I can’t find the link right now). Crackers will crack them anyway sooner or later. Or they can end up in public or not so public forums in a very short time. Next, he says you should raise up your prices and he’s also right. Both pieces of advise go together: you don’t put a public key in place to make your software impossible to copy. You put it in there to clearly state that making such a copy is illegal. Normal customers, users, will get a pirated copy of your software if they want to. It’s not hard and as of today it's not dangerous. But the corporations can’t do that, because they have codes of ethics to attend to. Also, their bottom line is not as affected by you as a regular user’s is. So my comment on this is: use a product key, so a customer will get your software from wherever he finds it, adopt it, and tell his boss about it so he can buy it. You may even get someone so into your software that he’ll buy it from you right after getting an illegal copy of it.

One very valid solution is to avoid the whole product key affair, and publish a free version of your software with a reduced set of features in it, and a full version on purchase. Of course, the rules of the game will remain the same. Pirate copies of your software will be unprotected. Remember: seeing your software in the pirate circles means your software is successful. If a cracker took the time to work on it, it probably means it’s worth it. This fact will not get you any money now, but it sure will make you money in the long run.

My general advice is:

1. Make your key easy to code. Not as easy as to make your key laughing stock from the cracking community, not as hard as to lose valuable time (your time) over it. Crackers will probably bypass your code instead of trying to solve your algorithm if it’s too hard.

2. Always use some sort of non-managed code for the key algorithm. Managed is just to easy to read, even when obfuscated. I mean, this guys debug your code in assembly to crack it, scrambled names will not be enough to stop them. Also, if you’re a Managed developer, remember that a signed assembly cannot be tampered with, but it can be read.

3. Validating your key in the setup is cool for usability, but it has nothing to do with security. MSI is a simple database and it can be very easily modified. Most software providers actually validate the key in an exe before the msi even starts up (that’s one of the reason that most software ships with setup.exe and setup.msi). I find that doing that is not really necessary if you do 4.

4. Always validate your key on startup of your product. If the key is invalid, you can load with a reduced set of features, or not load at all.

5. If you want to provide a time bomb (that is, trial software that will eventually expire), hide the expiration date (or something that you can convert to the expiration date) somewhere in the key.

6. Eliminating keys you find on the internet is an impossible race. There’s many more of them than there are of you. New keys will resurface within hours.

A good product key is like a good encryption algorithm. In this context, that means two things:

7. If you change a single bit of your product key, the rest of the key should change to accommodate your checksum. All the “digits” must change.

8. There should be a minimum (say, 10%) of valid product keys per bit. That is, if your product key is 32 bits (it won’t be), only 2 or 3 keys should be valid.

I created the key on a very simple algorithm I will not disclose, using Wix and a C++ dll. I’m planning on giving the details of the procedure on the next few posts.

Posted on Saturday, July 26, 2008 4:12 PM Setup | Back to top

Comments on this post: Product Keys and Setup – Random Thoughts

# re: Product Keys and Setup – Random Thoughts
Requesting Gravatar...
You don't even know what product it's protecting!! (can't tell you, sorry... but it's not that difficult to guess).

Anyway, I'll quote myself: "You put it in there to clearly state that making such a copy is illegal." If I handed a key over here, then I'll void that, making it less clear that hacking my product key is illegal. You got the product key from me, after all. That's not different from buying it.

On the other hand, you can be sure that if I find my product key online, I'll be more happy than sad. It would mean that people think the product is important enough to be sharing a means to get to it.
Left by Joaquin on Dec 01, 2008 10:43 AM

# re: Product Keys and Setup – Random Thoughts
Requesting Gravatar...
i need a registration key for reason adapted i threw away orig. packaging.
Left by terrell on May 12, 2009 3:28 PM

# re: Product Keys and Setup – Random Thoughts
Requesting Gravatar...
Left by TOMMIS JACKSON on Sep 24, 2009 4:34 PM

Your comment:
 (will show your gravatar)

Copyright © Joaquin Jares | Powered by: