License key generation

Dec 6, 2018 at 2:14pm
Hello!
I would like to know how to make license keys for my program? How to prevent the transfer of key to other users.
Do you use licenses for your programs?
Dec 10, 2018 at 6:45pm
Any ideas? Or it's secret information?
Dec 10, 2018 at 6:52pm
The user has to provide information that is in some way "correct".

Your program accept input from the user, and if it is correct, then they have provided a license.

That's the basics of it. What counts as "correct" depends on how clever you want your licensing to be.

It could be this simple:

1
2
3
4
5
6
7
int correct_value = 8;
cout << "Enter license:";
cin >> license;
if (license != correct_value)
{
  exit(1); // end program
}


Should it be impossible to look through the binary and find a correct license value?
Should it be impossible for licenses to be shared? What does that even mean? Should one user be able to install his software on more than one machine?
Should the program have to contact some online license server?
Should the license be time-limited?
Last edited on Dec 10, 2018 at 6:53pm
Dec 11, 2018 at 4:59pm
The question turned out to be quite serious. We need to think about many details.
I have already thought about some of the issues about which you are writing.
I think the user should be able to use the license for more than one device. And then there are questions: how to check that the user did not give the key to someone else?
And how to implement it?
I do not think that my program will be mega popular. I would like to foresee such trifles.
Dec 11, 2018 at 5:23pm
To restrict a license to one device, you need to either ensure that one license cannot be accepted on two devices simultaneously (which means your program will need to communicate with some central license server that you control) or you will need to make the license dependent on the specific machine it is to run on. For example, your license could only work on a specific PC that is in some way uniquely identifiable ( https://stackoverflow.com/questions/3443093/what-is-a-good-unique-pc-identifier ).
Dec 11, 2018 at 5:50pm
Alternatively: just don't worry about it. Check for a license and allow the user to use it on multiple systems even simultaneously, and trust that they will not share it with other people. If someone really wants to pirate your software they'll be able to do it regardless of what countermeasures you implement. Your time is better spent improving your software in other ways.
Dec 12, 2018 at 2:50pm
the trouble with this stuff is that you have to have a server if you want to make it live. that is if you want to know that at any given moment no key is used twice, then you need to have your program tap your server and update what key it is using per copy. That is an expense and aggravation. If you allow the program to be used offline (no connection to the server), then its already hacked (take your network offline and use it all you want).

You can tie the key to the hardware serial IDS (microsoft does or used to do this, change 2-3 pieces of hardware and its invalid). I don't know how they do it but it may be a library you can get if its a windows program. If you get extra serious (software worth thousands of dollars) you can force a hardware key (usb device needed to run software).

you would be wise to have the executable program hash itself and check its own value to ensure no one has tampered with it, else a half decent kid hacker can just bypass whatever you do (and even that isnt foolproof, if they can figure out how to bypass the hash as well, but its much harder if you make the hashing check intermingled with core functionality that breaks things if the check is bypassed).

People have been down all these roads. Find a good solution online in a library somewhere?
Dec 13, 2018 at 5:13pm
You can arrange the verification of keys using the server. But this is not the most reliable way.
Dec 14, 2018 at 5:57pm
Incredible! So many ideas! I am very grateful!
I think checking the key on the server is quite reliable protection? Is it?
Dec 14, 2018 at 6:26pm
the server gets you live real time accounting -- no 2 computers with the same key are able to go at once and you are alerted if you have someone try that.

It also gets you thousands of angry people if your server is down, or hit by DOS attacks, etc.

and Ill say it again, this is an expensive option.
- it consumes resources (energy, networking connections, VM server hosted somewhere, whatever )
- it consumes human resources (you need someone keeping it patched and secure and keeping it running, on-call 24/7, or hosting costs...)
- it causes problems if its down, slow, far from some consumers (eg server in Australia and consumers in idaho, whatever)
- its more expensive if you have a bunch of them scattered across the globe, or a cluster to handle a big customer load, etc.

and it still isnt foolproof.
Last edited on Dec 14, 2018 at 6:33pm
Dec 17, 2018 at 8:33pm
That's for sure! If the server crashes it can annoy the users. You will get bad reviews and a lot of problems. This method has its pluses and minuses.
Try ready licensing systems like Armdot and others. You can find many similar programs.
Dec 18, 2018 at 6:02pm
I think I understand you. I thought the server verification is quite reliable. But I see that it's not so.
I will try to use the program that you advised. I have not figured out how it works. Are there any guides?
Dec 18, 2018 at 11:46pm
I am sure you can find a guide online to the basic concepts and commonly used libraries. The details of any one package is likely to be harder to find, esp if its not opensource or something, as they likely protect their methods jealously.
Dec 19, 2018 at 7:50pm
Of course I will find guides. Thanks for the advice guys!
Dec 21, 2018 at 7:49pm
I think it is better to use ready-made solutions. Creating your own key generator can take a long time. It is better to spend this time improving your program!
It's my opinion.
Sincerely
Dec 24, 2018 at 5:32pm
You're right. I will use tips that are written above.
I improve my application all the time.
Topic archived. No new replies allowed.