First off let me say this, I am a small time developer enjoying a reasonable amount of success for a very specialized App that currently only runs with FM Go.
I am thinking of introducing another level of security to prevent Piracy of our App and am wondering if any one has implemented this. If so, how is it working for you. Or if there is a reason I shouldn’t implement it.
It is simply this. After the user installs the App they must register it before it will run. So, when they start to register he or she is presented with a dialog box with a button that simply says, “Send Registration Notice Email”.
When he or she does it simply sends us a notice via email that they are installing the App.
When they don’t the registration process shuts down the App preventing the registration and the App will not run without being registered.
In other words there is no way to use the App without sending the email.
Why bother since someone could simply send the email and register an illegal copy anyway? Even though it cannot prevent illegal registration it tells me what company is not paying for the extra copies that are being registered. That helps us know who to avoid when upgrades are released.
I've set up a system that does this job. It is a fairly easy thing to do in concept. Getting the details right is where you'll spend your time and effort.
Our system didn't need people to sign-up because we were installing systems onsite but your email sign-up process is sufficient.
Our system had a licence period and a partial-stenographic which could be verified. We used stenographic tokens because they are fairly random, long and complex and they hide in plain sight.
In the lead up to the licence expiry, from our end, we would send a email saying that the licence period is coming to an end and advise them how to pay. On payment we'd update their licence key and refresh the stenographic token.
We had a bunch of ways in which we allowed the test to fail gracefully (because you want to keep your paying customers) and we configured the system so that we could control it from our end.
The default we setup was that when licensing no longer active the system went into read-only mode.
Malcom, Thanks for the input. I need to learn about "stenographic tokens." If you have the time could you expound on that a bit more? Or send me a link to a paper or blog. I googled it and didn't get much of a return.
Stenographic tokens are a fancy way of using images to generate strings. Take my octopus user icon as an example. It's 30545 bytes. If we decide to implement a token of between 64 and 128 characters then that image has 30545 - 128 possible tokens. (Although we'd never use the first 50 bytes because its file type header that isn't unique). We can obtain a starting point at random, that is one part of the key, we can obtain a string of random length up to 128 characters from the icon, which is the second part, the icon itself is the third part. The token obtained is the result of a simple formula applied to an string.
If we provide the user with the token, they are seeing the token but they never see the image. They may or may not know that the length of the token is a part of the secret. With the image, the token length and the starting point we can regenerate the token. Or we can use the token to determine a starting point.
EZ,
I had to deal with this in the past for a few projects. In todays world, the simplest way to to have the app call home ( like FileMaker server calling home to check the license validation ). The downside to this approach is you have to have a server running all the time to be available so the app can check. There are a number of other benefits to this approach. Probably good for another thread or topic.
If you don't want to do the server, a second method is to build a routine based on a field like email address. You will probably collect this info for a download. Have them enter the email into the app. Take this info and build out a hash string using any of the method out there. From this string, you can create a reverse string for a match. Since you have the email from the registration, you can send out the unlock key. When they enter this key into the app, the app will have routine to create a key( it will use the same hash setup), you do a check and if it matches, you unlock the software. You can have it send you something that the unlock was successful or skip this.
Let the software run on a set number of days or allow them to create x number of records in demo mode. After the demo number of records is met or time, you can expire the software if key is not entered.
If you want to make it extra secure, you can tie it into the device ID and add this into the lock. There are other issues with this method, but it is extra secure. Again, probably another thread.
Thanks for those great insights. No system has 100% up-time, so you do have to factor in the risk that your system is down at the very moment that someone is verifying. That's relatively easy to do.
Malcolm, yes there will be down time, not everything is 100%. Look at AWS, Twitter, the big cell provider Rogers went down a few weeks ago here in Canada ( lucky I was not on Rogers, but some of my clients were ). I threw in a test to connection to server, if it was there, we validate, if not we skip until next time. The routine was part of my startup to check, once it is flagged, then routine is skipped. There are lots of different ways, it good to see the discussion.
App design now is about handling all the potential issues and user experience. If you want to lock it down, the same goes for the experience for the user, make is seamless.