I wanted to create a winform application that have a centralized security database. This application is portable, can be save to any PC and simply run the .exe to use, hence there will be many copies of this software. However, it will require a User login, this login account credentials will refer to centralized security database(centralized DB is for security purpose only). If the PC does not have a Internet connection, the software will not be able to identify the credentials. Hence, i came up with an ideal is to put a time stamp, if the last connection to centralized is DB is < 24h, local credential(DB copy from centralized DB) login is granted. But the problem i face now is, the time stamp and 24H limit will have to refer to current system time in the PC(which can be change easily to bypass the time stamp). what is the solution? Any other method that can control the User while the application goes offline?

  • Can the attacker setup his own decoy server that will act like the centralized database, and make the local software always happy? Commented Dec 10, 2014 at 9:08

2 Answers 2


There are several attack vectors here if someone wanted to pirate this software. They could modify the binary or replace the remote server with a fake one. In general, DotNET binaries can easily be disassembled or decompiled back to readable source code, for free, see http://www.jetbrains.com/decompiler/. Even worse, the code can also be edited and recompiled almost just as easily. So if you have any secrets or symmetric encryption keys in your sources, they will be compromised. This can be only mitigated a bit by using some 3rd party obfuscator but that is just delaying the inevitable. If you already have a method to bypass authentication based on timestamp in your code, you're actually making it even easier to abuse. Also the local copy of db could be used to set up a fake auth server.


Your scheme is vulnerable to replay attack: an attacker can manipulate the time and date setting of the local system in order to fool your app into accepting an expired security token.

Furthermore, since you're placing all security element inside your local storage, you simply cannot protect it against the local user: he could, for instance, run your app in a debugger, stop it right when it query your local DB and grab your authentication data from memory.

In other word, there is no foolproof way to protect your data in the way you want. All you can do it try to make it less easy through obfuscation.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .