in my firm, most of the software is secured by a couple of different antiquated licensing systems. For example, after setup the user has to start another program that tells him his calculated machine id. He needs to send us this id, which is embedded in a file, encrypted and shipped with another setup, that just copies the file in the relevant folder. Not only does this generate a lot of workload and a hurdle for the user, the decryption key needs to be embedded in our software and can easily be extracted, allowing the user to circumvent this "security" measure.

After developing my first application for this company, I would like to develop a prototype for a more advanced licensing system with my own service. I'm looking to run my general plan by you, I'm sure I've overlooked some things and would like to have them pointed out before bringing it to management..


  • Client automatically receives a license key after registration
  • Client enters this license key into my application
  • Application sends this key with machine information and sends a GET_LICENSE request to our server
  • Server checks if license key is in our system and returns a pgp encrypted message to client
  • Client uses its embedded public key to check the license file and the sign date (which should be secure, (as long it was signed on our side](http://www.pgp.net/pgpnet/pgp-faq/pgp-faq-message-signatures.html))
  • If there is no internet connection, start the application if license file is available and sign date is not older than n days
  • Update the license file every time a internet connection is made

Now I realize there is no complete safety, but this should give us a lot more security and benefit our honest customers with a more comfortable experience than before. A internet connection would only be required on first start and then every other day, but our application already needs a connection for most tasks. We would save the man hours for the manual license creation and communication with the customer while allowing him to sign up and use our application no matter of our office hours and availability. No credential information could be extracted from our application.


  • 2
    How do you deal with virtualization? How do you deal with changes in hardware? Basically you propose the same system as Microsoft uses. Their "flaws": After CPU/HDD/RAM/Network serials change (I think still 3 elements can be changed without triggering reactivation), Windows will complain and will generate a new machine id, which will be used to get a new license key from the Internet. We considered a similar system but dropped it again because clients need to be able to change hardware without being pursued with online activation. It´s an industrial application which is never online.
    – flohack
    Jan 19, 2016 at 10:36
  • Changes in hardware could be dealt with one license key per machineID, which can updated in our records. I don't care too much about virtualization, nothing I can do about it I think. My main focus is to make the process more streamlined for the honest user and protect our software better than embedding the key in a practically insecure file.
    – Sven
    Jan 19, 2016 at 10:43
  • 2
    Food for thought: Musicload dropped DRM alltogether because costs of handling client requests were higher than potential loses from piracy. theregister.co.uk/2007/03/20/musicload_drm_problems What you need is not only technical analysis but also a financial one.
    – Agent_L
    Jan 19, 2016 at 11:55

2 Answers 2


Your design is the basically the same as most licensing systems. One extra step is to obfuscate your application, so it is more difficult to decompile.

How secure is this? It will certainly hinder a typical user. In fact, even the older system with an embedded key will stop most users. While you say it is easy to extract the key, that is from the point of view of a skilled programmer, not a typical user.

It will not stop a skilled cracker. While they cannot create a fake license file, what they can do is modify the application binary and remove the code that checks for the license. Obfuscation makes this harder, but no obfuscation is foolproof.

The real concern though is that it only takes one skilled cracker to break your application, and they can then put the cracked version on Bittorrent. This may not be the end of the world. Many people will still buy the official version. Perhaps they're just honest, or don't know how to find cracked software, and a lot of people are rightly concerned about viruses coming with cracked software.

Ultimately, while your change is a security improvement, I don't think it makes a material difference to whether your software can be cracked. It does however sound like an excellent usability improvement.


Given the comment answer I would say that is a good enhancement of your existing architecture. Specifically, you can trigger alarms if your example different machine IDs appear for the same key in a close timeframe, lets say 1 week or even 1 month (reinstallation of a broken hardware right after first time installation can happen, but is unlikely). In this case however, you could contact the client and ask.

As a customer, if I was told that the license will be checked online every few days or so, I will not try to fool the system. I would maybe only try to get virtualization working, but you can counter this if you hash the MAC addresses for example. Even in a virtual environment MAC addies must be somehow unique ;)

Still maybe you want to consider a USB dongle system, to me even if it is "old-fashioned", it´s the most complicated system to fool.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .