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 '13 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 '13 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 '13 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 '13 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 '13 at 14:25

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 '13 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? – FrustratedWithFormsDesigner Jun 27 '13 at 15:17
  • Looking if there is a better alternative for what I use? – JNL Jun 27 '13 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. – FrustratedWithFormsDesigner Jun 27 '13 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 '13 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, privacy policy and cookie policy

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