I have been working on some software application and I update them every 6 months. Currently, the way I track the date is by extracting the date from the system when the user installs the application, encrypt it and store it in a file locally. Whenever the application is started, it checks if 6 months have passed, then it works or it doesn't, in which case it shows an error message telling the user to update.

If the user finds the encrypted date in the file they can simply replace it with one from a more recent install. I am wondering if there's a more secure way to do this?

  • You can add a file from the build and use this as a timestamp to check against.
    – Uwe Plonus
    Jun 27, 2013 at 13:57
  • @UwePlonus I did not get what do you mean by "add a file from the build?" Can you please help me understand it better. Thanks
    – JNL
    Jun 27, 2013 at 14:02
  • Simple create an empty file during the build of your software. Distribute this file with your software and use the file date as a reference.
    – Uwe Plonus
    Jun 27, 2013 at 14:03
  • ok...But when I build the Software, the file will have the date of the build and not when the user installs the software right?
    – JNL
    Jun 27, 2013 at 14:18
  • If you update the software or publish a build two days after a user installs the 'current' version, should they be waiting until they use it six months to check for updates, or should they be checking in two days?
    – JustinC
    Jun 27, 2013 at 14:25

2 Answers 2


Is there a specific problem you're having with the current model?

If the application is installed on systems that normally have internet access, you could do this on a server to avoid the situation where someone plays with their system clock and runs the application longer than 6 months.

When the application is installed, it registers itself with your service, and your service logs an application identifier (maybe a licence key) and the date of installation. Every time it starts, it checks with the server to see if 6 months have elapsed and then tells the user to update if it's been more than 6 months.

Possible disadvantages: It's a little more complicated. You now will need to build and maintain the registration/validation service. You also need to decide what should happen if the application cannot connect to the service. And someone who's really keen on getting around this could try and sniff the data you send to and from your service and then build their own service that always validates the application, and then reroute traffic intended to your service to their service instead. So of course, you'd want all traffic with this service to be encrypted.

If the user finds the encrypted date in the file they can simply replace it with one from a more recent install. I am wondering if there's a more secure way to do this?

So you're concerned that they will figure out that if they replace their existing file with a copy of the same file but from a newer installation, they will be able to bypass the 6-month limit? The answer above could still help with this problem, another idea posted below.

I don't know exactly how you're creating or encrypting the file, but one idea might be to include the installation datetime in the key that is used to encrypt/decrypt the file. That way, a file from a different installation would have a key that's different and so cannot be shared with other installations. Now the problem is storing this key somewhere safe, so that the user can't access it.

  • There is no problem with the current model. I was looking for a better alternative if possible. I am also looking for considerations if the user does not have any internet access. If with Internet access, the server registration works fine.
    – JNL
    Jun 27, 2013 at 15:07
  • @JNL: Well, if your current model is working fine, why change it? I don't really understand the business requirements that made you do it, but I probably don't need to. It sounds like a sane enough approach for a very specific problem, and if you say it's working, why mess with it? Jun 27, 2013 at 15:17
  • Looking if there is a better alternative for what I use?
    – JNL
    Jun 27, 2013 at 15:19
  • 2
    @JNL: If what you're doing works fine now, there might not be a better alternative. Better alternative sort of implies there's a problem with what you're currently doing. Jun 27, 2013 at 15:20
  • 1
    Just to build on @FrustratedWithFormsDesigner's point - How do you define "better" if you don't have any problems now?
    – Bobson
    Jun 27, 2013 at 15:31

You could do something like @Uwe describes, but have the file contain an encrypted string. The string will contain, as part of its value, the install date (or expiration date) and ... other stuff. What the other stuff is doesn't really matter unless you want other validations.

We do something similar but store the value in our app's database. Our encrypted string contains the app revision number, the "number of days from -base base- until license expires", and a few other things. On startup, we decrypt the string and calculate the number of days from -base date- until today. If the number is > than the encrypted value, they get a license warning. If the number is more than 30 days past warning date, they get a message and the app closes.

If the file (string) doesn't exist, the app doesn't start. If they dink the string and the decrypted value doesn't match the "mask" we use to parse it, the app doesn't start.

It's not foolproof for someone determined to beat it, but it serves our purpose of "secure enough".

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.