I'm working on a machine which needs to store usernames and passwords for the various operators, technicians, and engineers that may be using and configuring it. It is important that some functions be accessible only by engineers, some be accessible by technicians and engineers, and some be accessible by everyone. There must also be a way to add, remove, and change accounts. Finally, the data must be stored on the same physical computer as the application.

It's been suggested that we simply store the username, password, and privilege level in an INI file on the disk. This, obviously, is bad. I'd like to use a more secure system, with the goals that a low-privilege user:

  1. Cannot find a plain-text copy of anyone's password
  2. Cannot perform actions outside of their privilege scope

I believe that I have accomplished goal #1 by salting and hashing the password, storing the salt and hash on the disk, and authenticating against these values. I'm using the .NET framework, and the System.Security.Cryptography.Rfc2898DeriveBytes PBKDF2 hashing scheme for this purpose.

However, 2 is more difficult, because by storing the user accounts on the disk, the following attack is possible:

  1. Attacker makes a backup of the current application state
  2. Attacker resets the machine to the clean/initial state by deleting backed-up files
  3. Machine must now provide a mechanism to add user accounts, such offering an admin password which is displayed only on the first run
  4. Attacker gives themselves desired privileges and executes previously restricted action
  5. Attacker restores old machine state

I can't see a way around this attack. Is there anything I can do? How are fully-offline authentication systems, such as Windows or Linux user accounts, protected from this sort of attack?

I do realize that an attacker with this kind of access could modify or inspect the application itself and could add a physical or software keylogger, but that's not really something I can protect against, so I want to focus on making the authentication mechanism as secure as possible.

2 Answers 2


Basically, don't let the attacker modify the application state.

Now, I'm not sure how file permissions are enforced on Windows, so just take this answer as high-level advice. You will have to figure out the specifics yourself.

Basically, operating systems like Linux prevent this sort of things from happening by requiring a privileged account to modify, remove and sometimes even read an important file. Modern Linux enforces this in a variety of ways, including POSIX permissions, access control lists and SELinux.

Applying this to your situation (in Linux-speak), I would require that the application runs as a specific operating system user account and owns the files that provide application state and other relevant information. This removes the ability of normal users using the system to modify the application state.

  • That makes sense. It does seem to add the requirement that anyone who needs to start or re-start the application would need to enter the credentials of the OS user account, but I suppose that's a reasonable requirement.
    – kvermeer
    Commented Oct 9, 2013 at 11:43

I do not know if your step 3 ("Machine must now provide...") comes from a specific requirement or not. On my side, I would think it fair that, if one removes the main data files of an application, the application just doesn't start anymore.

In such case, you may use an encrypted database to store application state and credentials. On the software installation media, the database already exists with default administration password to be replaced (the application can even enforce this change upon first login). And if the database file is missing, the application start fails upon a "Data file missing" error.

This way, the application's users database is never left unprotected and an attacker cannot easily retrieve post-setup administration privilege.

  • Well, if it's possible to get administration privilege once by running the installer, then it might be possible to back up the encrypted database, run the installer again, use the default password to get access, and then replace the database with the old credentials. I think this comes back to Terry's answer that I need to use OS-level controls to make sure that the users can't modify application state, including running the installation media.
    – kvermeer
    Commented Nov 8, 2013 at 13:33
  • @kvermeer: Of course OS-level control is safer, but depending on your application prerequisite you may not have the choice. In your comment, you postulate that the low-privileged user has got both the installer and the default admin password, in my idea these should remain between sysadmin hands (similarly, if you rely on OS-level protection, then OS administrative account credential must remains between sysadmin hands). Commented Nov 8, 2013 at 13:43

You must log in to answer this question.

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