Authorization in offline application

Question

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.

Answer 1

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.

Answer 2

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.