Validation Key for DB - hash email and exp date (1 Viewer)

mounty76 · Jul 17, 2019

Hello,

I'm totally new to trying to figure this out, I've read lots but quite confused!

I've made a db that I want to add a licence key to so that the db shuts down unless a valid licence key is entered by the user. It doesn't need to be totally secure and if people go to the lengths to hack it then so be it, it is more for the honest user to prevent them using it free of charge.

Is is possible to do the following:

1. I create a hash Licence key based on users email and the expiry date I want to give them for using the db.

2. They enter the licence key into their db on startup (first time only, or when old key expires)

3. The users db decodes the licence key and removes the date part of it, the db then uses this as a validity date. If the date is < Now() then it shows a message to contact me for new activation key.

I was hoping the above could be quite easy to achieve....but I'm not so sure! :banghead:

Thank you very much for any advice!

theDBguy · Jul 17, 2019

Hi. Definitely possible but complexity depends on implementation. For instance, let's say the customer's email is user@company.com and the expiry date is 12/31/2019. You can certainly create a "hash" with the following value: user20191231
You can then easily parse that to get the expiration date. But if you want to create a more complicated hash than that, then parsing and decoding would also get as complex. All you need is to create a "rule" or "algorithm" for hashing your value and the equivalent process to decode it. You can make up your own or search for what's already available. For simple ones, you should just create your own because it's less likely anyone would be able to figure out your "algorithm." For complex ones, you can use what's already available but there's a chance someone can figure out how to break it (although it might take a long time).

gemma-the-husky · Jul 17, 2019

The hard bit is the expiry date.

you can't really do this with a hash (I don't think), as a hash is a one-way function.

if the expiry date is 31/7/19 (say) then you can't know whether the hashed value for any other date is legit, just by comparing it to the hash value for the expiry date. I think you have to find a way to encrypt the date with a reversible process so you can recover the true expiry date. I use a combination of encryption plus hashing.

mounty76 · Jul 17, 2019

Hi theDBguy, Thanks for this, makes sense. Do you know any code to hash a value such as "user12/21/2019" then to extract/decode this back to just the date?

theDBguy · Jul 17, 2019

mounty76 said:
Hi theDBguy, Thanks for this, makes sense. Do you know any code to hash a value such as "user12/21/2019" then to extract/decode this back to just the date?

Hi. Since you will be collecting two pieces of information for/from the user, you can control how they get "hashed" together. The simplest approach would be to use the following format for the above hash: 20191221user
With that, you can easily grab the "date part" by simply using:

Code:

Val("20191221user")

From there, you should be able to convert the result into a date value.

PS. Caveat... Of course, if you use a simple algorithm like this example, then it's also very easy for anyone to figure out how to circumvent your system.

mounty76 · Jul 17, 2019

Hi gemma-the-husky,

Ah I didn't realise that hashing was one way. Hmm I see what you mean about being a legit date, potentially they could just try different 'licence keys' and end up with a combination that works as a future date 200 years from now. Any ideas to make this work....easier the better

CJ_London · Jul 17, 2019

it is more for the honest user to prevent them using it free of charge.

so the bad guys go free

And the honest guy can copy the app to 100 of his friends?

Code:

add a licence key to so that the db shuts down

that's a bit harsh - suggest start sending warning messages a month or two beforehand, then rather than a total shutdown (which might make you liable if the app is business critical) make it so it still works but certain key functionality is disabled (perhaps unable to print or add new records). Also make sure your terms and conditions explain what will happen at the end of the license period and that they are confirmed as read by your client.

One well know way to get around date based licences is to change the system date

mounty76 · Jul 17, 2019

Hi CJ, agree but for now I'm struggling with it being simple, my code is very very novice!

isladogs · Jul 17, 2019

In my experience, doing what you suggest isn't simple...that is providing you do it properly. If you don't do it properly there is no point doing it at all.

Simple XOR hashing is pointless -its almost trivial to hack. I use RC4 encryption which should more than meet your needs. The good news is that its two way (though of course that means its not suitable for very sensitive data such as credit card data).

You can find more details about RC4 encryption and all required code as part of this article on my website http://www.mendipdatasystems.co.uk/encrypted-split-no-strings-db/459456634

I also use activation as part of one of my security challenges http://www.mendipdatasystems.co.uk/activation/4594409030 but to see how it works you'll need to solve the challenge first

arnelgp · Jul 17, 2019

create a table with fields like:

License (text) - the license
Expiry (date) the expiry date.
Valid (yes/no)

fill all the license with anything you want.
fill the first expiry date as to when the corrensponding will expire.

first time use of db:
create a form that will be your starup form.
1. on its code, dlookup the lisence where the date is not null and save to variable.
2. dlookup the Valid field where the license is same as the one you saved on the variable.
if valid field is not set to No, show an input box and ask for the license.
check if the entere license is correct.
if correct set the Valid field to yes.

consequent use of db:
same as step 1 and 2.
if Valid is set, check if expiry date has lapsed.
if lapsed, dlookup the next License where the expiry is null.
ask for correct license.
if correct, set the expiry date field, set Valid field to Yes.

note the table should be hidden.
using tabledef you can hide it by setting its Attributes = Attributes Or dbHiddenObject.

before hiding make sure you copy and paste the table to your own db so you can send the correct license for expired ones.

mounty76 · Jul 18, 2019

Hi arnelgp,

That sounds just want I am after, a simple solution. Do you have any code that can help me out? Sorry I'm not a code genius!

Thank you in advance

Micron · Jul 18, 2019

its almost trivial to back

I suspect you meant 'hack'?
If dates are going to be involved, one has to consider working in code with only US format?
Interesting - no one mentioned registry keys for this. Perhaps because it's not as simple as a table.

isladogs · Jul 18, 2019

I did indeed mean 'hack'. Now corrected. Thanks

arnelgp · Jul 18, 2019

actually it was just in my head, then the challenge came.
see xxxxxLicense table for all the license.
notice there is no expiry date yet, will leave it like that for a moment.

open form Main Form.
see the code on Main form and the LicenseForm.

you may hide xxxxxLicense table using the Test sub on Module1.
goodluck.

edit: I modified the licenseForm.

isladogs · Jul 18, 2019

Arnel
I've had a quick look at your example and would suggest that its a good starting point but needs additional work before it is suitable for the intended purpose.
The following isn't intended as criticism but to encourage the OP to add additional security

Hiding the table isn't enough to deter hacking as its just as easy for hackers to 'unhide' the table (I'm deliberately not going to say how that's done in this thread).
So I repeat my original comment that license keys should be 'scrambled' with a strong 128 bit encryption key using RC4 or similar. Better still don't store the key in the app at all.

Also as yourself point out in the app, you can easily test this by altering the system date. Similarly, the same 'trick' can be used to circumvent the expiry date.

BTW Your original app had a compile error but fixed in the edit. I've noticed that you never seem to use Option Explicit in your code module which surprises me as it should be standard for any Access project. I'd also recommend that variable declaration is required in VBE options.

isladogs · Jul 18, 2019

Hi Micron
I do use registry keys as an extra layer of security.
Using those alone would also be easy to hack
The key value(s) are then compared with whatever info is in the app itself.
A bit like two factor authentication systems used in online banking and elsewhere

mounty76 · Jul 18, 2019

Hi arnelgp, thanks for this, much appreciated. The people most likely to use my db are not prolific hackers and so this simple solution is perfect, most of the people that use it don't know how to make a table in access so I don't think I need to worry about it being hacked, there isn't anything too confidential on there either.

I'm sure this is easy but how do I put a countdown from expiry-30 until expiry so that each time they open the db (when within 30 days of expiry) it says:

XX days until your licence expires, please contact.....

Thanks very much in advance

isladogs · Jul 18, 2019

You could create a simple function GetExpiryDate that uses a DLookup to get the expiry date for that licence.
Then use something like

Code:

if GetExpiryDate-Date<=30 Then MsgBox GetExpiryDate-Date & "days until your licence expires …."

mounty76 · Jul 18, 2019

Hi isladogs,

Sorry my code is terrible, how do I do a DLookup to find the date which is being used for the validation key that is being used?

Cheers

isladogs · Jul 18, 2019

The code will be something like

Code:

Function GetExpiryDate()

GetExpiryDate=Dlookup("Field name", "Table Name", "Filter Criteria for current record")

End Function

For example
DLookup("ExpiryDate","tblLicenceInfo", "ID =" & Forms!YourFormName.ID)

For detailed info, look in Access help

Validation Key for DB - hash email and exp date (1 Viewer)

Registered User.

I’m here to help

Super Moderator

Registered User.

I’m here to help

Registered User.

Super Moderator

Registered User.

MVP / VIP

..forever waiting... waiting for jellybean!

Registered User.

AWF VIP

MVP / VIP

..forever waiting... waiting for jellybean!

Attachments

MVP / VIP

MVP / VIP

Registered User.

MVP / VIP

Registered User.

MVP / VIP

Similar threads

Users who are viewing this thread