Question

I have an application that creates a serial key as follows:

Take customername
Sign customername using privatekey and sha/dsa algorithm

Then license can be checked by decoding with public key, and checking cuastomername matches

This works okay except that the generated serial is rather long. So it is not really practical for customer to type in the serial key instead they have to provide a serial with in a file, which is rather different to how mist applications and work and is confusing.

Many other applications just provide the user with a Guid when they make a purchase

i.e 5bd1060b-8608-4817-93ca-207f7c828e2f

and the user has to enter their email address and guid to license their application.

This looks like a neater solution for the user but I don't understand how such an application verifies a valid guid from an invalid guid unless its done all online by checking emailaddress/guid pairs on a database. But I really would like some kind of verification to be done without requiring an online check otherwise:

a>The application will not work if internet connection/my server down or b>they can circumvent check by disabling internet access

EDIT:

My understanding solution as proposed by answer below:

User makes purchase
Take emailaddress + salt
Encrypt with SHA1 gives 160bit hash
Convert to hex notation gives 20 hex values, i.e 40 characters
Lop of last 8 characters to give a Guid
Email User Gui and Email address which they enter into program Program verifies this pairing by taking the email address, adding salt, encrypting ectera and checking generates a valid guid.

My main problem with this is that I need to store the salt in the program somewhere, therefore if the hacker finds the salt and works out what Im doing they can create a valid license key generator for any email address.

My current method for another program:

I have generated a public key/private key pair
User makes purchase
I generate a license by signing the emailaddress
BaseEncode the generated license
Send license to user
Program verifies license by basedecoding and decrypting with public key

My problem has been that when I sign the emailaddress is too long so I end up putting it in a file instead of the user entering it into a field, but maybe the problem is that I am base64encoding rather than converting to Hex.

How long can the output of signing be, does it depend on the length of the input or is it always the same ?

Because I decrypt the key with the public key I canot lop some chars of the license key, but if the generate key is only 40 characters I guess that is okay

I think the advantage of this method is that even if hacker works out how I'm doing things, they cannot create a license generator because they do not, and cannot get the private key because it is only stored on my server. They could only generate licenses if they created a new private/public key pairing and then if my application had the public key encoded in itself the application could reject the license anyway.

Of course they could hack the application, but if the application was updated regularly this would become alot of effort.

So in summary: Have I understood this correctly, which method is best, and how much data is generated for second approach.

Was it helpful?

Solution

I think the signature approach is currently best practice. Btw. there are a number of free libs that cover this topic.

The length of the license key is at least determined by the signature key length - a 1024 bit key produces a 128 byte license (if no other payload is added).

Often the license file consists of more information on the licensed use itself, like validity period, licensed submodules, throughput... - the signature itself is embedded within this structure. This way you gain flexibility and i strongly advise this solution, even if the license gets even bigger.

For importing the license in an application you can adopt a hybrid way (like we did). On one hand you can provide the classic "import license file" solution. On the other, we generate a random, short ID (like your GUID) and associate it with the license data. Upon registration the user enters the the short ID and the application looks up the complete license via HTTP. You must be online only once, you can still provide complex licenses and the user only needs a short ID.

EDIT

  1. The length of s signature is the length of the key. E.g. 1024 bit (or 128 byte)
  2. You can use this signature alone if your application knows what data is signed (e.g. the mail)
  3. You can sign a "license document" containing more properties than only the mail. In this case the license contains property AND signature (and is, accordingly, longer than only the signature)
  4. You dont need online connection for license check. Just import a license with the application and check whenever you like.
  5. An addition to license file import you CAN adopt an online download of the license file using a short ID as a key. The license is downloaded and offline. So you have the best of both worlds.

OTHER TIPS

You may just hash the user info concatenated with a "secret" salt and then truncate the hash.

Hackers - provided they are interested in your program - will crack it, by reverse engineering the source: they'll find both the hash algorithm and the secret salt.

But this is to happen also with your sign&verify solution: they can just bypass the check making it return true.

So the sign&verify solution is more complex but not safer.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top