How to create a unique license key for my access database

[VBANewBie :)]

Hello everyone , I have a program which I need to distribute and need a way to create a unique license key for each device , What I have done so far is :

1. I made a form in the db which pull HDD serial and CPU serial then combine them in one string with separator then encrypt the string using XOR method and put the encrypted text in a textbox visible to the user .
2. The next step is to receive that string from the user and decrypt on my device and split it to get the vital data for license (HDD & CPU) .
3. the third step which I'm missing that I need to do something with the data then encrypt it again to send back .
4. The final step , The user receive the product key and put it in another textbox , The form will decrypt then check (I don't know what to check for !) then activate the program if the product turned to be valid by inserting the cpu and hdd serial in a table .

Am I on the right path ? Or is there any better way ? .. Any help appreciated
Thanks

 

[The_Doc_Man]

You are using a method that others have tried with varying success. Search this forum for the topic "License Key" and look in the "Similar thread" heading below the main thread because you might find many other articles on the subject.

The tricky part of this is your 3rd/4th step where you supply something to become part of the proposed license key. Anything that you supply here runs into the problem that when you decrypt the key, the elements you supplied would be visible so that if someone actually DID hack in, they would be able to see what you did. That defeats the intent of the encryption.

I believe the more successful methods don't involve actually encrypting something to be decrypted, but rather use the idea of a hashed key where you don't actually decrypt anything. You merely regenerate the hash and compare it to the key hash. And there, the trick is to NOT store the extra hashing parameters in the DB, but rather have your installation process put the key factors in some obscure place.

 

[VBANewBie :)]

You are using a method that others have tried with varying success. Search this forum for the topic "License Key" and look in the "Similar thread" heading below the main thread because you might find many other articles on the subject.

The tricky part of this is your 3rd/4th step where you supply something to become part of the proposed license key. Anything that you supply here runs into the problem that when you decrypt the key, the elements you supplied would be visible so that if someone actually DID hack in, they would be able to see what you did. That defeats the intent of the encryption.

I believe the more successful methods don't involve actually encrypting something to be decrypted, but rather use the idea of a hashed key where you don't actually decrypt anything. You merely regenerate the hash and compare it to the key hash. And there, the trick is to NOT store the extra hashing parameters in the DB, but rather have your installation process put the key factors in some obscure place.

Thanks for advice , Your help is deeply appreciated .

 

[theDBguy]

Generating and using license keys can be as complicated or as simple as you would like it to be. You have decided to combine both HDD and CPU info and wondering how to use them. One idea is to use the customer's personal information as well. For example, when you receive the HDD and CPU information from the user, you can combine it with their email address. When you send the result back to them, your program/application can use the info from the registration or settings table or even prompt them for the info you're looking for to verify their license key. Just a thought...

 

[Pat Hartman]

It would be helpful to have an overview of the entire process. Is this an application you are selling to the public? Are you trying to restrict the number of installs at ONE site or are these independent installs so that each install stands alone with its own BE?

My partner and I decided for the application that we sell, that verifying seat licenses was going to be more trouble than it was worth given that we would need to create a website to control it. Is that what you are doing? So, rather than restrict the number of users, we opted to restrict the data. The application performed benefits audits. So, the license was for a number of concurrent audits. So, the client could buy 1, 3, 10, unlimited number of concurrent audits. If he tried to start a new audit, the number of existing audits was compared to what he was authorized for and so he could not start a new audit when his limit was reached without closing and archiving an open audit to free one up.

Also, our product was sold to corporations and wasn't the kind of software that the users would be inclined to try to steal and resell so there wasn't much risk on that front. Our license agreement was pretty clear on what the client could and couldn't do with the software and so we left it at that. We provided a "token" which included encoded data that identified when the license expired and what features and the number of audits the client had paid for.