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?
6
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.
9
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”.