AW: OT: locking software to one specific machine?

[Brian Yennie]

While this thread is alive, I've long been curious what the criticisms would be of the following scheme, for a product with low to medium security needs. This does assume that you require an internet connection for registration, but that seems to be a generally acceptable requirement these days.

1) Generate as many (or as few) *random* keys as you need
2) Put them in a database
3) User inputs key, app contacts hosted script which checks if the key is in the database
4) If YES, expire that key
5) If NO, lock out the user for a few seconds
6) Go back to #1 if you sell more keys

Point being, if you are ok with requiring an internet connection, why generate a key which has *any* pattern that can be cracked? Guessing a random key you can do very simple math to know the chances of someone cracking it by brute force, and there will be no other method short of getting a hold of your database (and let's face it, if someone is cracking your servers, you might as well give up). For example if you have "only" 1,000 valid keys and something like a 16 digit HEX code, a cracker has about a 1 in 20,000,000,000,000,000 chance of guessing a correct code. Even if you don't lock out after failures... that's 20 quadrillion tries we're talking about. As a bonus crackers may expend a lot of effort looking for a pattern which doesn't exist.

I probably haven't given this as much thought since I've never really had to implement it, but I'm keen to hear opinions from those that have. What am I missing? Is there an inherent fear of keeping the database secure which trumps keeping an algorithm secret?

> Marty Knapp wrote:
>> I like the idea of pre-generated keys. It seems like a good in-between
>> method. If your user then registered their key and someone else
>> subsequently tried to register the same number you would have some
>> recourse. I don't want to get bogged down in lots of administrative
>> hassles, so I like this method. Does anyone have suggestions about
>> setting up something like this? And a method for verifying the key?
> 
> 
> Challenging, but fun:
> ---------------------
> 
> Start by reading these for inspiration:
> 
> The Plain Truth about Casual Software Piracy
> by Matt Slot, Ambrosia Software
> <http://www.windowsusers.org/piracy.html>
> 
> Anti Cracking FAQ
> How to make cracking your programs a little harder
> <http://www.inner-smile.com/nocrack.phtml>
> 
> Now devise a scheme of between 12 and 20 characters in which some of the characters must be in a specific range to be valid, and others are derived from combinations of others.  For example, character 10 could be the ASCII equivalent of the average of characters 9, 4, and 2, and character 2 could be the sum of characters 1 and 5 minus character 8, etc.  It's sometimes useful to have some characters use values you can derive meaning from, such as the version number, if needed.  Use that to generate your keys.
> 
> Avoid schemes that produce any "1" or "0" characters since those will be mistyped as "l" and "O" by many users, raising support requests with complaints of a "bad reg code".  This will reduce the range of acceptable keys, but you should still be able to produce at least 10,000 unique keys from most schemes you can think up in a few minutes. If you sell 10,000 copies you've made more than enough money to finance your upgrade with a new reg scheme. :)
> 
> Also provide a Paste Code button in your reg window so they don't need to type the code at all, and handle Cmd-V yourself by cleaning the clipboardData["text"] of any extraneous characters before pasting into your field (people will include trailing returns and other garbage when copying from the reg email you sent them).
> 
> Then write the inverse of the generator to validate your codes, but break up the validation into multiple handlers each doing a small part of it, using obscure function names strewn all over your code base with lots of red-herring handlers with similar names littered among them. Extra bonus points if the handlers you call also call others; the more the merrier.  Anyone tracing your code in a low-level debugger will find it far more annoying than it's worth.
> 
> Run all your keys through the validator before shipping, to ensure the generator and the validator are in synch.  This batch validator should also check uniqueness of all keys to avoid having a single key sent to multiple users.
> 
> Then of course add at least a half-second delay for validation somewhere in your sequence to thrwart brute-force attacks.  A half-second won't bother a user, but for automated attempts it means the difference between hours and years.
> 
> Then lock your stack with a good password, after writing down your algo somewhere since your code will be unreadable to even yourself.  Use v4.0 to build, since the password protection is much stronger.
> 
> Repeat with each new version, changing your scheme substantially between versions so that all the old keygens that showed up on those overseas servers within a week of your last release will no longer work with your new version.
> 
> 
> 
> Less challenging, but no less fun:
> ---------------------------------
> 
> Just use Jacque Gay's Zygodact
> Automated Registration System for Revolution
> <http://www.hyperactivesw.com/solutions_zygodact.html>