How to Store (And Manage) Application License Information

Where can I store (and manage) Application license information?

In my opinion the point is you have to change how you manage your license.

Where

If they delete license data file then trial restarts? Do not start application if file doesn't exist and create it with an install action first time it's installed.

Now you face a second problem: what if they uninstall and reinstall application? Second step is to move this file to application data folder (for example Environment.SpecialFolder.CommonApplicationData). This is just little bit more safe (because application data won't be deleted when uninstall) but it's still possible for them to manually find and delete it. If application will be installed by low privileges users there isn't much you can do (you can't try to hide license somewhere in Registry).

Now it's a game between you and crackers. They'll win, always. You'll only make life of legitimate users more hard so read cum grano salis. Where you may store license data:

Registry. Pro: easy to do. Cons: easy to crack and for low privileges user it's valid only for one user per time. A registry key (in a per-user base) can be somehow hidden if it has \0 in its name. Take a look to this nice post.
File. Pro: easy to do and IMO little bit more safe than Registry. Cons: easy to crack (but you can hide it more, see later).
Application itself (appending data to your executable, few words about that on this post). Pro: harder to detect. Cons: an antivirus may see this as...a virus and an application update may delete license too (of course if you don't handle this situation properly) so it'll make your code and deployment more complicated.

How to hide license in a file?

If you're going with a file (it doesn't matter where it's located) you may consider to make crackers life (little bit) harder. Two solutions come to my mind now:

Alternate Data Streams. File is attached to another file and they won't see it with just a search in Windows Explorer. Of course there are utilities to manage them but at least they have to explictly search for it.
Hide it inside application data (a bitmap, for example, using steganography). They just don't know it's license data, what's more safe? Problem is they can easy decompile your C# program to see what you do (see paragraph about Code Obfuscation).

Probably many others (fantasy here is our master) but don't forget...crackers will find it (if they really want) so you have to balance your effort.

How

Keeping your license schema you're now on a dead path. Decision you have to take is if the risk they use trial longer than allowed is higher than risk they stop to use your application because of boring protection.

Validation

If you can assume they have a network connection then you may validate license on-line (only first time they run your application) using some unique ID (even if it's about Windows 8 you may take a look to this post here on SO). Server side validation can be pretty tricky (if you want to do it in the right way), in this post is explained an example of program flow to manage that in a proper way.

Data Obfuscation/Encryption

Your license file/data is now in a safe place. Hardly crackers will find it. Now you need another step: obfuscation. If your license data is in plain text once they found your file it's too easy to change it. You have some options (ordered by increased security and complexity):

Obfuscate your files. If they can't understand what's inside a file with a simple text editor (or even a hex editor) then they'll need more time and effort to crack it. For example you may compress them: see this post about XML file obfuscation with compression. Note that also a simple base64 encoding will obfuscate your text files.
Encrypt them wit a symmetric algorithm. Even a very simple one will work well, here you're just trying to hide data. See this post for an example. I don't see a reason to prefer this method to a simpler obfuscation.
Encrypt them with an asymmetric algorithm. This kind of encryption is a big step in complexity and security and it'll be (very) useful only if license token is provided by a server/external entity. In this case it'll obfuscate license signed with its private key. Client application will validate signature with its public key and even if cracker will find this file (and decompile your code to read public key) they still won't be able to change it because they don't have private key.

Please note that data obfuscation/encryption can be used in conjunction with above mentioned steganography (for example to hide encrypted license file inside an image).

Code Obfuscation

If you're not using license signing with asymmetric encryption then last step is to obfuscate your code. Whatever you will do they'll be able to see your code, check your algorithm and workaround it. So sad, you're deploying instructions manual! Obfuscate with an Obfuscator if you want but what I strongly suggest is to move your license check in a less obvious place.

Put all your license related code in a separate DLL. Sign it (be aware that signed assemblies may be decompiled and recompiled to remove signing, there are even tools to do it almost automatically).
Pack it inside your executable resources (with a not so obvious name) and do not deploy DLL.
Handle event AppDomain.AssemblyResolve, when your DLL will be needed at run-time you'll unpack in memory and return its stream of bytes. See more about this technique in this Jeffrey Richter's post.

I like this method because they'll see there is a license check but...they won't find license code. Of course any good cracker will solve this issue in 10 minutes but you'll be (little bit more) safe from random ones.

Conclusions

To summarize a little bit this is a list of what you may do to provide a stronger license check (you can skip one or more steps, of course, but this will reduce safety):

Split your license check code in two assemblies (one to perform the check and manage license and the other to provide a public interface to that engine).
Strong sign all your assemblies.
Embed your License Engine assembly inside your License Interface assembly (see Code Obfuscation section).
Create a License server that will manage your licenses. Be careful to make it secure, to have secure connection and secure authentication (see Validation section).
Save license file locally in a safe location (see Where section) and encrypted with an asymmetric encryption algorithm (see Data Obfuscation section).
Sometimes validate license with your License Server (see Validation section).

Addendum: Software Protection Dongles

A small addendum about hardware keys (Software protection dongles). They're an invaluable tool to protect your software but you have to design your protection even more carefully. You can assume hardware itself is highly secure but weak points are its connection with computer and communication with your software.

Imagine to simply store your license into the key, a cracker may use an external USB (assuming your SPD is USB) to share same key with multiple computers. You should also store some hardware unique ID within the key but in this case weak point is connection (hardware can be emulated by a software driver). It's a pretty easy crack and this false sense of security ("I'm using Software Protection Dongle, my software is then safe") will make your application even more vulnerable (because you risk to forget other basic protections to simplify license management).

Cost vs benefits for a poor designed protection using SPD should make you consider to use a normal USB pen drive. It costs 1 $ instead of 15/20$ (or much more) for a SPD and you have same level of protection against casual crackers. Of course it won't stop a serious cracker but also a poor designed SPD won't stop it.

A true protection (assuming you're not running on a DRM enabled device) is a dongle which can also execute your code. If you can move some basic algorithms (at least to decrypt vital - and dynamic - support files) into the key then to crack your software they will need to crack hardware. For a half-decent dongle this is a very very very hard task. More carefully you design this and more code you move into the key and more you'll be safe.

In any case you should doubt about marketing campaigns: software protection with a dongle isn't easier. It can be (much) more safe but it isn't as easy as vendors say. In my opinion plug-n-play protection cost is too high compared to its benefits (benefits = how much it'll make crackers' life harder).

How to store sensitive information on client side using wpf

If it's on the client side, it's impossible to ever be 100% secure without server verification: you can't encrypt a decryption key, you have to leave it in plaintext somewhere.

At the same time it's normally sufficient to just add a verification to the licence - eg the certificate has a line which is the hash of the certificate, plus a salt hardcoded in your application. If the user tries to edit their licence, the hash will change and you can throw an error.

With decryption keys, you should look at public/private key pairs, but as above, you can't encrypt the decryption key (at least, not without storing another unencrypted key)

How to manage licensing to enable features for a web application?

I would implement several tables in database, as it is shown below:

Sample Image

There will be the following entities: User, License and Device

And these entities will be related to each other as it is shown above. Every license will contain information about qty of licensed devices.

When a device connects to your service your service recognizes it by its id, which is being sent by device upon the connection. Then you can check, is the device registered, and what license is related to this device.

Limitations on quantity of devices will be checked upon device registration.

When a user registers a device (adds information to tables: Devices and LicensedDevices), your code should check the quantity of already registered devices with this license against devicesQty field value in Licenses table.

And if devicesQty value allows to add more devices, then your code adds new device to the database.

UPDATE:

To control quantity of licensed devices you need to register these devices (for instance - using unique ids of these devices). Otherwise you cannot control quantity of devices which are using your service.

One device connects, works, disconnects, then another, then another and so on. How can you control quantity in this case? I think there is no way unless registering ids of these devices.

And if a user changes his device to a new one, then there should be a procedure to update information about a registered device.

If your customer uses only web-browser to use your services, then the only way to control license/devices is to bind userid+password+deviceId to a license. And check this information upon logging in to your web-service/web-servers.

If you are using a native application on mobile devices to connect to your web-service then there is more sophisticated way.

Implement license key generation/verification via asymetric encryption approach.

For each user generate public and private key. Then store private key in your database and do not show it to anyone.

Let say your public key is: ABC-123-456

Use Base64 algorithm to convert public key bytes to alphanumeric characters.

Then, upon selling a license generate an arbitrary unique license code.

Let say your license code is: XYZ-789-012

And provide end-users with public key and license code: ABC-123-456 and XYZ-789-012

User sets public key and license code to the custom mobile application settings. And this application encrypts all sending data with this public key. And license code is included to the data package before encrypting it.

When your server receives a data from a device, it finds appropriate user by deviceId, then it finds appropriate private key to decrypt the data package. And then it inspects this data package on correctness.

How to build a licensing system in C#?

Your wants can be fulfilled by easily creating a string variable in My.Settings but as this is a about licensing,use :

 IO.File.WriteAllText(IO.Directory.GetCurrentDirectory + "\license.abc","license string here")

you may even want to encrypt the file,for that :

class Encryptor
{
    public static string Key = "license here";

    public static string Encrypt (string decrypted)
    {
        byte[] textbytes = ASCIIEncoding.ASCII.GetBytes(decrypted);
        AesCryptoServiceProvider endec = new AesCryptoServiceProvider();
        endec.BlockSize = 128;
        endec.KeySize = 256;
        endec.Key = ASCIIEncoding.ASCII.GetBytes(Key);
        endec.Padding = PaddingMode.PKCS7;
        endec.Mode = CipherMode.CBC;
        ICryptoTransform icrypt = endec.CreateEncryptor(endec.Key);
        byte[] enc = icrypt.TransformFinalBlock(textbytes, 0, textbytes.Length);
        icrypt.Dispose();
        return Convert.ToBase64String(enc);
    }

Another bet would be store the license in registry :

 Microsoft.Win32.RegistryKey key;  
 key = Microsoft.Win32.Registry.CurrentUser.CreateSubKey("key");  
 key.SetValue("key", "licenseKeyHere");  
 key.Close();

Your best bet is to let the activation happen online,let it connect to your database over the net and activate.You can go with SQL Server,MySql or other similar products.

And one more thing,as u mentioned in ur qs,u want to embed a file to the app so tht the user can't see it ? Why not, use my 1st/2nd method and finally do this :

 File.SetAttributes(path, File.GetAttributes(path) | FileAttributes.Hidden);

How do I implement license management for on-site installation of webapps (preferably cross-platform)?

Don't. Every hour that you spend writing a license key system is an hour that you are not spending fixing bugs or adding features. By writing a license management system, you are spending resources in order to reduce the value of your product!

where to save activation data of the application?

The issue you mentioned is one you need to consider, but there are many others:

How can users activate licenses on systems that don't have a network connection?
If you follow the standard practice of node-locking each license (automatically reading some system parameters such as MAC address, host name, hard disk ID etc.) and checking these at run time, how will you accommodate users who upgrade their system and so cause one of these parameters to change?
What about users who want to relocate their license to a different system, such as moving it from their desktop to the laptop, or to a new system?
What about users who call you (and they will) and say: "Help, my system has crashed so I need to get my license running on a different machine?"
If you are using the activation system to set a license time limit, such as 30 days for a trial license or a year for a subscription, how can you protect against users who try to cheat on this by mis-setting their system clock either before they activate their license or after it is activated?
What if you decide to offer different versions of your application - can your activation system manage this? e.g. enable or configure product features for each user based on their activation license, but all from one executable
How about reporting on licenses activated - does your server capture the data on licenses activated and provide reports, alert etc.?
What if someone wants to buy a pool of, say, 20 licenses? Do you have to provide 20 different activation IDs, or can you provide one ID that will allow 20 licenses to be activated?

Just some things to think about based on years of experience in the field.

protect Java Application by licence or key

This depends entirely on how secure you want to make it...

The problem with Java is that you can reverse compile it. So if someone wanted to, they could download your software, reverse compile it, and then remove whatever security you have put in place (and then redistribute it if they wanted).

This is only a problem if you plan on going mass market and selling it and piracy would actually be a problem though.

If you're not concerned about this, then you can either go for online, or offline checking.

The company I work with uses the online method; there are a few steps:

EDIT: I've since changed how this works, as the old way was a maintenance nightmare.

A license file
- (this can contain whatever you want in reality, it just has to be unique per user. Most people normally go with general garb;
- name
- company
- email
- and then a key. i.e. the JDU8-AJS9-88DF-SASF-ASF9 kind of thing you often see.
The program generates a hash from the license file.
1. put all the data from the license file into a string
2. pass the string to a hashing function this page can show you how.
have the program check online (on your server). The data gets encoded in an HTML request (post/get/json/whatever you want) and submitted to your license verification page, which then verifies the data. Included in the data is a randomly generated string, which is used by the verification page to generate another password. This is then returned to the program, which has also used the random string to generate its own password. If the two match, the program starts up.

To generate the keys, just use the same hashing function, and then upload the hash to your server.

If you want it to be offline, you could include the hashes in the code I guess and check against them there.

I should point out, however, that I'm not a security expert by any means, I just develop for a company as a portion of a Ph.D. and this is just how I did it.

Edit: this image might be helpful:

Sample Image

Second Edit:

I have now included "offline verification" in the process. It's not really offline verification, it just uses the user as a proxy - they need to access the internet another way.

it works like this:

no internet connection found: supply the user with a 4 digit code
user goes to offline verification page (optimized for mobile use too)
user selects which software they use from the dropdown list
user enters their username (this field remembers entries)
user enters the code the program gave them and submits
webpage provides a 4 digit code, which they then enter into the program, and it starts.
program adds some special data to the license file meaning that this process won't need to be repeated for the next week/month/however long.

every time the program successfully verifies online, it also adds an offline access password to the license file, which means it's robust against temporary internet downtime, and will only stop working if the internet is down for more than a week/month/however long it's set up to work for.

How to generate and validate a software license key?

Caveat: you can't prevent users from pirating, but only make it easier for honest users to do the right thing.

Assuming you don't want to do a special build for each user, then:

Generate yourself a secret key for the product
Take the user's name
Concatentate the users name and the secret key and hash with (for example) SHA1
Unpack the SHA1 hash as an alphanumeric string. This is the individual user's "Product Key"
Within the program, do the same hash, and compare with the product key. If equal, OK.

But, I repeat: this won't prevent piracy

I have recently read that this approach is not cryptographically very sound. But this solution is already weak (as the software itself has to include the secret key somewhere), so I don't think this discovery invalidates the solution as far as it goes.

Just thought I really ought to mention this, though; if you're planning to derive something else from this, beware.

Best way to store license key persistently on i-device

The "standard" way to do it is to have Apple manage the licensing for you via in-app purchasing or subscriptions, they provide a secure implementation for checking if something is paid for, but this may not be an option for you.

If you need to roll it yourself, you need to use assymetric encryption, with a private key on a server that nobody can access (except you) and a public key distributed in the app. You also need the [UIDevice currentDevice].identifierForVendor.UUIDString value on the device, which is a value unique to that device which cannot be changed by the user (unless they jail break).

The server encrypts some data like 2014-03-23,purchased-three-month-license,<device-identifier-for-vendor>,<long-random-number> and gives the encrypted data to the device as the license key.

The device has the public key, and uses it to decrypt the license key. Then it checks the result to see if the date is in the last three months, the device identifier matches the device's actual identifier, and verifies that the long random number is there and at least 10 digits or something (it doesn't matter what the random number is, it just needs to be there).

Anybody who jail breaks their device will still be able to bypass your security. There is no way to prevent this. But it will take the user a lot of work, they'll probably just pay instead.

All the libraries you need for the encryption are built in, but they're low level APIs and a bit complicated to use and it's easy to screw it up. I recommend RNCryptor as a high level wrapper around them.

Also note that if the user uninstalls your app, then re-installs it (or sometimes when Xcode installs a new build) the identifierForVendor will change to a new value. Apple enforces this to protect user privacy, there's no way around it. You will need to have the server re-generate a new license key based on the new identifier... perhaps by asking the user to enter an email address and password. You can prevent piracy by monitoring how many times a particular email address is used. If they generate license keys 5 times in 30 days, then you could flag them as a pirate.

Whatever license key the "woocommerce store plugin" is generating will not work, because it won't be using [UIDevice currentDevice].identifierForVendor.UUIDString as part of the license key generation. Without that value, it's going to be trivial for anybody to pirate your software.

There is no such thing as "something untouchable inside the application bundle". The only such thing is the Secure Enclave in Apple's hardware. And to protect user privacy app developers are not allowed to use it directly. identifierForVendor is the only option.

In older versions of iOS there were more options, but they were abused by advertising companies tracking Apple's customers, and so one by one Apple has blocked access over the years.