How to create a key to protect the application

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

Take customername Sign customername using privatekey and sha/dsa algorithm 

Then the license can be checked by decoding using the public key, and check the correspondence of the name cuastomername

This works fine, except the generated serial number is quite long. Thus, it is not necessary for customers to enter a serial key; instead, they must provide a serial number in a file that is different from how applications work and works, and is confusing.

Many other apps simply provide Guid to the user when they make a purchase.

ie 5bd1060b-8608-4817-93ca-207f7c828e2f

and the user must enter their email address and specify in order to license their application.

This seems like a tidier solution for the user, but I don’t understand how such an application checks for a valid guid from an invalid manual, unless it has done everything online by checking emailaddress / guid pairs in the database. But I really would like some kind of check to be performed without the need for an online check:

a> The application will not work if the Internet connection / my server or b> they can bypass the check by disabling Internet access.

EDIT:

My understanding suggested below:

User makes a purchase
Take Email + Salt Encryption with SHA1 gives a 160-bit hash
Converting to hexadecimal notation gives 20 hexadecimal values, i.e. 40 characters
Lop of the last 8 characters to give a hint Email User Gui and the email address that they enter into the program The program checks this connection, taking the email address, adding salt, encrypting ectera and checking generates a valid guid.

My main problem is that I need to store the salt in the program somewhere, so if the hacker finds the salt and finds out what I'm doing, they can create a valid key generator for any email address.

My current method for another program:

I created a public key / private key pair
User makes a purchase
I generate a license by signing an email address
BaseEncode generated license
Send user license
The program checks the license based on encryption and decryption using the public key

My problem was that when I sign the emailaddress address is too long, so in the end I put it in a file instead of the user entering it in the field, but maybe the problem is that I base64encoding instead of converting to Hex.

How long can the output of a signature be, does it depend on the length of the input, or is it always one?

Since I am decrypting the public key, I cannot intercept some characters of the license key, but if the generation key is only 40 characters, I think this is normal

I think the advantage of this method is that even if the hacker works on how I do it, they can’t create a license generator because they don’t, and they can’t get the private key because it is stored only on my server. They could only generate licenses if they created a new private / public key, and then if my application had a public key, the application itself could reject the license in any case.

Of course, they can hack the application, but if the application is updated regularly, it will be a big effort.

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

+4
source share
2 answers

I believe that the signature approach is currently the best practice. Btw. There are a number of free libraries that cover this topic.

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

Often a license file consists of more information about the licensed use itself, such as expiration date, licensed submodules, bandwidth ... - the signature itself is built into this structure. This way you get flexibility, and I highly recommend this solution, even if the license gets even bigger.

To import a license in the application, you can use the hybrid method (like us). On the one hand, you can provide the classic solution "import license file". On the other hand, we generate a random short identifier (for example, your GUID) and associate it with the license data. After registration, the user enters a short identifier, and the application views the full license through HTTP. You only have to be online once, you can still provide complex licenses, and the user only needs a short identifier.

EDIT

  • The s-signature length is the key length. For instance. 1024 bits (or 128 bytes)
  • You can use this signature separately if your application knows what data is signed (for example, mail)
  • You can sign a “license document” containing more properties than just mail. In this case, the license contains the And signature property (and, accordingly, is longer than the signature only)
  • You do not need an online connection to check your license. Just import the license with the application and check whenever you want.
  • In addition to importing the license file, you can use the online download of the license file using a short identifier as the key. The license is downloaded and disabled. So you have the best of both worlds.
+1
source

You can simply hash the user information concatenated with the "secret" salt, and then truncate the hash.

Hackers - provided they are interested in your program - will crack it by reversing the engineering of the source: they will find both a hash algorithm and a secret salt.

But this should happen with your decision to verify the sign and confirm: they can simply bypass the verification to return true.

Thus, the & sign verifies the solution, is more complex, but not more secure.

0
source

All Articles