licensing an access application

[suepowell]

HI.

I am writing an application in access 2007 that I want to sell on, and I want to do all I can to make it secure so it can't be copied arround and given away easily. ( I know if someone is determined to pinch it it is very difficult to stop entirely).

I am setting up the backend with the navigation turned off so if it is opened they can't see anything. I know it can be opened using shift, but I'm not that bothered if they see their own data and the tables. As it is Access they will be able to get there with odbc or another database Access anyway.

To protect the front end I am hiding the navigation bar, turning off the standard ribbons and disabling standard menu's. I am then creating an .accde file to protect the code. Again I know that they can see the forms etc by opening using the shift key and could mess up the forms, but they can't see the code so I feel fairly happy with that.

My question is: Is there a way of time limiting the use of the database and requiring a password to be entered to continue using it.

I would like to provide a test version as many programs do, so potential customers can try it before they buy, but I want to stop them using it after a length of time if they don't pay.

We are also intending to offer this on a monthly fee, and again I want to be able to stop the program working if they stop paying, maybe a new password every 6 months or so, to protect me without annoying them too much! This means a password needs to expire after given time, and another one to be required and to work.

Your thoughts on this would be greatly appreciated.

Thanks

Sue

 

[Atomic Shrimp]

I am then creating an .accde file to protect the code. Again I know that they can see the forms etc by opening using the shift key and could mess up the forms, but they can't see the code so I feel fairly happy with that.

They can't.
Holding down the shift key will prevent it from launching your startup form, but they still can't open forms in design mode in an accde version of your front end.

 

[suepowell]

Thanks,

I'm safer than I thought!

Sue

 

[Atomic Shrimp]

We are also intending to offer this on a monthly fee, and again I want to be able to stop the program working if they stop paying, maybe a new password every 6 months or so, to protect me without annoying them too much! This means a password needs to expire after given time, and another one to be required and to work.

I think probably the best way to do this is to encrypt a string that contains mostly useless chaff, but has an expiry date in it (maybe a license number too, if there's a possibility of your clients communicating with each other), then have your program decrypt it, pull out the expiry date and check it. This way, you can send the new license key by email and you can store the last one they entered in a table somewhere - just don't publish your encryption method.

If you do choose to do something like this, you ought to spare a thought about what you want to happen in the event that you are no longer able or willing to support the application (i.e. if you fall under a bus, or if your company goes out of business, or you leave for another job) - do you want this to result in the permanent expiry of all user licenses?
If you do want them to be able to continue using the system, how will you prepare for that to happen? (possibly, without your input at all)

 

[neileg]

To protect your clients they may ask you to put the source code in escrow. This means that the code is held by a third party (a specialist escrow company or a law firm, perhaps) and is released to the client if certain events happen, like you falling under a bus.

 

[Atomic Shrimp]

Or you could just place a license key in escrow - and design the key to permanently unlock the application.

 

[suepowell]

Hi Mike,

Thanks for the idea. I do intend to put the code and or liciense into escrow or equivalent once we start selling the product.

Could you explain in a bit more detail how to do what you have suggested, how would I encript the string, where would I store it? Would I ask for the password on logon where the date had expired.

Sorry to be a bit thick about this but it is getting outside my comfort zone!

Thanks

Sue

 

[Atomic Shrimp]

Hi Sue

I would probably approach it like this:

1. Create a single-record table to store settings and configuration, create a text field in it to hold the license key and other data such as some sort of userID number

2. Disable some important parts of your application, such as buttons to create a new record, or menu options to print reports, etc.

3. Create a small form, bound to the single-record table - in the OnLoad event code of the form, it needs to do something like this:
-read and decrypt the contents of the license key field
-test substrings of the decrypted license key field against the current date and anything else you think appropriate, such as the userID number
-If the above test is successful, the code should enable the parts of the application mentioned in step 2, then close the mini-form.
-if the test is not successful, the form can remain open and offer opportunities to enter and test a new license key.

On the structure of license keys, I would personally set it up something like this:

Example (non-encrypted) key: 8doiulk20091231-001poifojeirgjrweaf

-the first character of the string denotes the start position - 8 - of the expiry date substring - so your code just needs to pull out that bit and compare it against the current date - the digits immediately following the date could be the user license ID (so that client 001 doesn't share his key with client 002, who hasn't paid his bill)
Everything else in the key string is just random chaff - so a valid key for the same user could also be:
4iu20091231-001kwkdososisdfpoiu

But you don't want the user to be able to read the key like that, or they would just be able to create their own, so it needs encryption. You could really go to town on this, but it probably isn't necessary to go to too much trouble - you could just use a simple rotation algorithm like this one:
http://www.a1vbcode.com/snippet-1648.asp

So you encrypt the key, send it to the user by email - he pastes it into the form, which stores it - still in encrypted form - in the single-record table. The only time it's decrypted is in the code, when your mini-form examines it for validity.

Hope that makes some kind of sense...

 

[suepowell]

Thanks Mike,

That looks really well explained.

I'll have a go over the next few days and let you know.

Thnaks again.

Sue

 

[NigelShaw]

Hi,

i purchased an activeX to handle my licencing as it handles the demo, rental, floating licence and full purchase licence. have a look at sagekey.com as it is very good. it was about $400 but spread that against your forecast sales might not be too bad as you can still use it on other products. it also handles options i.e. different modules purchased etc. the installer is good too combining 2007 runtime and gets round the vista UAC issue of writing to registry.

a very valuable tool for me.

Nigel

 

[DCrake]

I have attached a simple txt file that describes the way of using the DB.Properties collection to store data about the application. This is very useful when wanting to retain registration details.

David

 

[mcdhappy80]

Hi Sue

-test substrings of the decrypted license key field against the current date and anything else you think appropriate, such as the userID number

On the structure of license keys, I would personally set it up something like this:

Example (non-encrypted) key: 8doiulk20091231-001poifojeirgjrweaf

-the first character of the string denotes the start position - 8 - of the expiry date substring - so your code just needs to pull out that bit and compare it against the current date - the digits immediately following the date could be the user license ID (so that client 001 doesn't share his key with client 002, who hasn't paid his bill)
Everything else in the key string is just random chaff - so a valid key for the same user could also be:
4iu20091231-001kwkdososisdfpoiu

I will try this method You mentioned.
What I don't know how to do is to extract the date sub string. Which functions would You use for this?
Will it matter in which format is the date stored (as I see here the date is 2009-12-31)?
In my database I store the date in this format dd. mmmm. yyyy.
If I'm storing and reading date in that format (for eg. 01. Jun. 2009) in what format would I put the date in the substring?

What code construction would You use to compare the dates, I'm having problem with this?
Would You convert the dates to string, or would You compare them as date data types?
What operators would You use to compare dates, or precisely, how would You compare if the current date doesn't exceeds the future date (date in the substring)?

Thank You.

 

[rob.low]

I have attached a simple txt file that describes the way of using the DB.Properties collection to store data about the application. This is very useful when wanting to retain registration details.

David

I agree with DCrake

The database's properties is a good way to go to store your reg key.

 

[mcdhappy80]

I have attached a simple txt file that describes the way of using the DB.Properties collection to store data about the application. This is very useful when wanting to retain registration details.

David

I've read Tip 2.2 from GetProperty.txt and I add this question to my questions above:

If I append the property which will store the licence key that will be evaluated with each start of the database, can someone see it (because it is a database property) from within Access, or it can only be access via VBA (thus meaning It's completely inaccessible if I distribute .accde version of database)?

Thank You.

 

[DCrake]

Access gives you the power to create your own database properties. Unless the person knows that you have used this functionality to store the license key and they know the name of the property, I douldt that it will be discovered. This is of course that they do not have access to your code, as they would see you calling the property on start up.

David

 

[mcdhappy80]

Thank You for Your answer David, This is definitively better method than storing the key in a visible spot such as table.

I'm still having problems with other stuff I asked about earlier, and since no one answered I'll repeat my question(s) again. I'm doing this because I don't want to open another topic because the things I need help about concern licencing application and things mentioned earlier.

Here are the questions:

What I don't know how to do is to extract the date sub string. Which functions would You use for this?
Will it matter in which format is the date stored (as I see here the date is 2009-12-31)?
In my database I store the date in this format dd. mmmm. yyyy.
If I'm storing and reading date in that format (for eg. 01. Jun. 2009) in what format would I put the date in the substring?

What code construction would You use to compare the dates, I'm having problem with this?
Would You convert the dates to string, or would You compare them as date data types?
What operators would You use to compare dates, or precisely, how would You compare if the current date doesn't exceeds the future date (date in the substring)?

If someone already has the code template for this better for me , if not, well, give me a hint and I'll do the rest

Thanks Again.

 

[NigelShaw]

Hi

If someone trialed your program and data was written to the database properties as previously suggested, what's to stop them reinstalling as the original won't have the properties object until the program is run. Also, what prevents a user changing the computer date to say 20 years ahead from now, installing your program and then changing the time back. It will take then 20 years before a date can be greater than the date embedded into a keycode or database property.

Just a thought

nigel

 

[rob.low]

Hi

If someone trialed your program and data was written to the database properties as previously suggested, what's to stop them reinstalling as the original won't have the properties object until the program is run. Also, what prevents a user changing the computer date to say 20 years ahead from now, installing your program and then changing the time back. It will take then 20 years before a date can be greater than the date embedded into a keycode or database property.

Just a thought

nigel

If it is coded right the expiry date is preset before given to the client and even if the database is not used it will expire and can not be reinstalled after the expirey date
this is how i code my databases you could also code a backdate to stop the client backdateing the system date

 

[NigelShaw]

Hi

if the expiry is preset, what happens if it is not installed until after the expiry date? If the program is created to be distributed over the Internet to anyone who wants to buy it, then you'll be really busy having to continually update your expiry dates.

A good way is a registry key holding a date. There is no preset code, your app simply looks for the key.
If it doesn't exist, it's never been installed before so your demo starts.
If it does exist, check validation. If validation fails, compare dates for demo period. If that fails, close app otherwise run demo.

You can name a registry key key anything you like and bury it deep so it can't be found.

That could save you a lot of time rather than you havi g to keep changing an expiry date.

Nidge

 

[rob.low]

Hi

if the expiry is preset, what happens if it is not installed until after the expiry date? If the program is created to be distributed over the Internet to anyone who wants to buy it, then you'll be really busy having to continually update your expiry dates.

A good way is a registry key holding a date. There is no preset code, your app simply looks for the key.
If it doesn't exist, it's never been installed before so your demo starts.
If it does exist, check validation. If validation fails, compare dates for demo period. If that fails, close app otherwise run demo.

You can name a registry key key anything you like and bury it deep so it can't be found.

That could save you a lot of time rather than you havi g to keep changing an expiry date.

Nidge

yep it could be a problem for some ..i dont distribute my databases over the internet as i only supply local govoment
there is so meany pros and cons in the diferant ways in protecting your database
the registery is a good way also ..its what ever works for your own situation i guess theres so meny good threads and posts on here about it .. lots of good reading loll

rob