Activation Code

[ruthcarlton]

I am getting ready to release a demo version of my solution.

I have read a number of posts in this forum, and although I acknowledge that it would be more secure to offer a limited feature version, I am opting for a 15 day full feature demo.

I am not making it possible to activate the demo version because I don't know a way to create an activation code which is unique to a copy of the demo. In other words...what would stop people from distributing an activation code, unlocking demo versions at will?

[BobWeaver]

If you make it a 15 day demo, it's easy to fool by changing the computer's date. But, if you make it so that it will only launch a limited number of times (like 15 times), then you have better security. Your startup script can keep track of the number of launches in a global field which can't be easily modified by the user. Of course, nothing is perfectly secure. To make it more secure, use the developer tool to strip the design info. The user can still install another copy of the demo and get an additional 15 launches, but would have to re-enter all his/her data. For this reason, it may be a good idea to disable any import facility.

[Charles Delfs]

Protolight (sp?) has a free ( did I say Free?) plugin ( Crypto) that gives back the Volume Serial Number or the hard drive. An almost completly unique #. from that you can create an instalation key that the app can email to you to register. then you hash an unlock key and send it to the user. they paste it into the unlock input field and you app de-hashes the 'ok to unlock' flag and ta-da. Each install is different and they can't just copy it to another hard drive.

Charles

[CobaltSky]

Hi Ruth,

/*QUOTE : what would stop people from distributing an activation code, unlocking demo versions at will : END QUOTE*/

The answer is nothing much (except maybe personal ethics, if they have some) - but then, what would stop them from distributing the fully functional copy of your software once they've bought it? Same difference.

In either case, a useful technique is to make the activation code link to the registered user's name, and then have your solution place that conspiculously on screens and print-outs, so at least if someone is using a copy they haven't paid for they will have to suffer the 'embarrassment' of advertising the fact. Short of hardware dongles, it's about the best you can do.

FWIW, if you're interested, you'll find a demo of a system that generates access codes that are linked by one-way encryption to user names at: http://www.nightwing.com.au/FileMaker/KeyCodeMaker/

There are a few systems of this type around, including some - like KeyCodeMaker - that are FileMaker native, and others that require plug-ins. They offer varying levesl of security, convenience and ease of implementation, so it depends how far you want to go, and who is in your target market (eg how strenuously and with how much expertise you expect them to try to hack past your copy protection systems).

A couple of further thoughts.. Bob mentioned that users can set the system clock back and suggested one alternative to work around it. Another alternative is to have every script in your solution update the current system date and time (preferably encrypted) in fields that are not readily user-accessible. Then your solution will be able to detect if the system clock has been set backwards.

Moreover, if you want to discourage users from re-installing your demo to get an additional fifteen days, you might like to consider using a plug-in to store an independent record of the installation status (or on Windows, just interrogate the registry file) and abort any subsequent installation attempts on the same machine. Again, very savvy users will find a way around this, but you'll have raised the bar and made it more 'inconvenient' for freeloaders.

The object is to ensure it will be easier (and cheaper - time is money) for the bulk of your potential users to purchase your solution, than to thrash around trying to circumvent your safeguards. You'll never keep everyone out (Dj, for example, will leap past all security measures in less than sixty seconds ) but you'll need to detemine what is the right level of security for your target market.

[Anatoli]

a useful technique is to make the activation code link to the registered user's name, and then have your solution place that conspiculously on screens and print-outs, so at least if someone is using a copy they haven't paid for they will have to suffer the 'embarrassment' of advertising the fact.

I was using that on DOS database 20 years ago, where all reports from system where "stamped" by Company name, address and VAT number on all printouts.

When submitting that reports/printouts to the Government or invoices to their customers it was next to impossible for someone else to use that system.