Licensing: How to deal with date/local time tampering of a computer?

Asked

Viewed 203 times

9

I am developing an application (Desktop) that requires license renewal periodically, following a model Saas.

The model of the licence shall function as follows::

  • The license will be downloaded from a web service. This requires the user to be connected to the internet in the first use of the product;
  • The license will be updated periodically by an automatic background process, connecting to the service and renewing the expiration date;
  • If the user in question breaks the subscription (stops paying) or no longer connects to the licensing server, he can use the product until a certain date (expiry date of the last downloaded license).

In this case, how to deal with tampering on the local machine date/time, so that the user is prevented from using the product even by rewinding the clock from his computer?

  • If your system is totally offline, it has a mix of techniques. One of them is that you store the amount of system usage linked to some newly entered data. Even if the date is changed, there is no going back with the "hours consumed". If your system is online, just check the date and time externally, preferably from your server, with some key to checksum the request.

3 answers

6


If the user in question breaks the subscription (stops paying) or no longer connects to the licensing server, he can use the product until a certain date (expiry date of the last downloaded license).

Do not use dates. Use number of days. For example, each monthly payment is entitled to use for 28-31 days.

Every boot-up of your service:

  • validate the time of the last update versus the current time.

    • If the date is different (past or future, whatever) remove a day.
    • If system time is inferior (the clock was rigged), remove a day.
  • Store the current moment, so it can be validated on the next boot-up.

So, attempts to circumvent the counter will always count against malicious user, but without harming the honest user.

As @Bacco originally mentioned in your comment (the credit is yours, Bacco!), it is interesting that you validate this structure against some other source to avoid restarting the file containing the time of the last review. The solution it presents (storing in the encrypted file the last ID of a known table and frequently used for database writing operations, for example) is simple, robust and easy to implement.

Solutions such as an NTP remote server (network time) or an endpoint that returns the current date in an encrypted way (and that must necessarily be accessible or the user loses immediate access) are feasible and depend on the model you want to use.

3

It has many ways of doing.

One that I recommend is that you mark the date and time of entry and exit of your system. If it comes back more than two hours than the last departure time, you ask it to reconnect to re-validate the license and without it blocks access.

The worst case of this method is that it can be used for 30 continuous days (managing the date and time of the system well every time and having an extra job).

Another option is to scan the system and look at date and time of one or several files from the operating system and your program to take a look if there are any inconsistencies.

2

You can compare to the application’s own database by checking if there are no records with a date and time later than the date set on the local computer. For if the date has been tampered with an hour the dates of the base records will begin to give divergences.

Example:

Let’s assume that the date adulterated was set at 02/29/2016. In a given table generated the following records:

29/02/2016 08:00:00, 29/02/2016 09:00:00, 29/02/2016 13:00:00 and 29/02/2016 18:37:00

Tomorrow when the application is used the date will continue being 02/29/2016 (or some smaller date). Let’s assume that new records were generated in this table:

29/02/2016 10:30:00

Do you understand the inconsistency? As I am entering a record on 29/02/2016 at 10:30 am if I already have records on the same day with higher hours. In this case the inconsistency is detected and you can crash the application because it is a sign that they are trying to bypass the license system.

You can have a table in the application just to log the hours every hour and create a routine to detect the inconsistency or you can use even some existing table that has date and time and manages records with some frequency.

Another option may also be to compare with the event logs of windows application (Event Viewer) instead of using its base.

Browser other questions tagged

You are not signed in. Login or sign up in order to post.