Page 1 of 1
Revolution standalone protection and license management
Posted: Thu Jul 05, 2007 7:54 pm
I was wondering the best way to go about protecting a Revolution standalone to allow it to be distributed as a demo but then allow licensed users to turn it on to be a full featured application. I am thinking of two possible ways. I need some help as to how to do these.
1. License registration through software.
-are there any examples of code of how to implement a registration process where users enter a registration key and then the software is unlocked.
2. Hardware keys such as HASP from Aladdin Systems or Wibu Systems
-Are these compatible with revolution standalones?
-Would this have to be done through a plugin or extension?
-Are there examples of code as to how to do this?
Posted: Fri Jul 06, 2007 2:11 pm
I have never sold a protected shareware/demo app, but if i ever do, I'd probably do it somewhat like this:
The application would let the user enter some data, like their name and email. From the data he entered, for example by a script on a server, or by you on your own machine (if you don't do automate selling), would then a key be generated. The key should be generated on a secure platform, namely NOT the user's machine, and be encrypted as good as possible. In addition the key would contain data only you know, like a randomised string, but be unique for each key.
The randomised string is there so you can check which user gave your key away, and disable it for updates. Maybe you could even add a date, so you could theoretically disable based on buying date. Also, the key can't be too long, or you'll lose usability.
The application would check the data and the key against each other, to validate it. So if for example the email is entered wrongly, the application would not activate. For added security, you could move the check to your server, but that requires your buyer to be online while activating. If you make the key check on the server, you'll thus lose the ability to recheck at startup, and a hacker could write a script which automatically tries to generate a valid key, based on the check.
A bigger problem is the storage of keys within your application, or code to decipher keys. Especially on Rev apps, which have a very weak build in encryption, which only applies to scripts. Even novice dabblers will be able to read fields and custom properties, and a beginner hacker will be able to read your scripts. So even if you encrypt data using the encryption dll, it won't be save, as all information to decrypt would be available to most attackers in your application.
You probably already know this, but here a general note on encrypting stuff:
Security and keys are not a end of all means, and can't be made perfect or all-encompassing. Therefore, you have to value your development time carefully, to not exaggerate the protection, because it will lose you time to develop other, for the user more useful features.
Posted: Mon Oct 06, 2008 6:00 pm
Thank you, Bvg, for a solid and reasonable layout of the approaches and challenges.
I am curious if the concerns that you have raised about the security of key handling mechanisms, esp any one might embed into a runrev app, are still going concerns in runrev 3?
I am very interested as I've not yet bought a copy of runrev, though it looks very good. I am trying to solve this very problem of licensing control and don't want to buy runrev if it can't do, or can't be made to do, a sensible licensing control scheme.
That is, I have an idea that I put together in Filemaker 9 Advanced and can package as an FMP runtime. This idea is meant to be a saleable product targeted at the general public. Just playing with runrev I'm able to see that with it and SQLite I'm able to do everything I was doing in FMP. But both have the same problem as far as I can tell, which is how to control the licensing of your runtime.
Filemaker doesn't have any good way to generate encrypted or even just well-hashed keys of any kind, at least not without a looooooong process of scripting and calcs, and though runrev can be made to do such things, if your concerns about the security of the key generation & validation methods being open to even the most noob-green hacker... well then, what's the point?
I.e., why bother building redistributable runtimes with runrev if those runtimes can't be controlled in terms of licensing? I must be missing something...