I have desktop application written in C# with three user roles and some predefined users. It is also possible to create another users or change passwords to predefined users. App has to work offline on Windows XP and newer.
What is the best way to work with user credentials on local machine if I have to have some predefined users? I thought that Data Protection API (DPAPI) is the best way how to handle this, but if I understood it well, it only works for one Windows users, so it is useless for me, because I have to ship predefined users with app installation and it is definitely not the best idea to hold those predefined users in source code (even if I save them with DPAPI to disk after installation).

1 Answer 1


Do you need to test the credentials or really store it ?

If all you want is check whether the user knows a given credentials, then use a secure password key derivation function (for instance, PKBDF2, BCrypt or SCrypt) instead.

If you really need to store the credentials (for instance, you need to forward it to an external service), then the answer is that you need to rethink your model:

  • If you're providing pre-filled passwords for a remote service (for instance, you want all your users to share a specific account on a mail server), then that means you're using hard-coded passwords and that is really bad: you cannot possibly secure it and obtaining these passwords, even if you obfuscate then, is usually very easy for an attacker to obtain it. And once one attacker has obtained that password, he can leak it for everyone else to use.
  • If your pre-filled password are actually just initial values that are supposed to be changed later, then leave them blank and force the user to change them during the installation.
  • These credentials are for just for the app, so it is enough, if I store only some sort of hash. The problem is (if I understood everything right), that anyone can "easily" look into source code via reverse engineering. If "anyone" can see the correct function and its parameters and is also able to see the correct derivation key (which at the end has to be saved somewhere on the hard drive), how this approach is better? Parameters have to be the same for all installations of this app (predefined accounts), so one can create rainbow table and, because of the known hash, use it pretty easily.
    – Artholl
    Commented Jan 6, 2016 at 21:07
  • It's a one.way hash: you CANNOT get back to the password from the hash. That being said, there is no sure way to protect a local application: anyone knowledgeable enough can change the validation code to cause it to accept any password. Also, if you're shipping the same app with the same passwords and not forcing these passwords to be changed, then a single failure of protecting these password will cause all your install to become vulnerable. It's not a good model
    – Stephane
    Commented Jan 7, 2016 at 8:50
  • I know that I am not able to get back password from hash, but if you know the hash and the function with parameters, then it is just "easy" brute force attack to find at least one password which generates the same hash. You don't need to know exactly the same password. It is enough to know the hash and the right function (and its parameters). If there are also some password limitations, than the brute force is even faster (e.g. length from 6 to 20 characters, at least one number). So from what you wrote, it looks pretty impossible to get good security with the local app (at least on Windows).
    – Artholl
    Commented Jan 7, 2016 at 9:33
  • No you can't. Please take a moment to review what the suggested KDF I suggested do: you'll see that they are all resistant to brute-forcing and rainbow table attacks. That won't really save you from weak passwords (nothing will) but it'll make it much, much harder to crack even a moderately complex password.
    – Stephane
    Commented Jan 7, 2016 at 9:53
  • As for local app security, it's not limited to windows: it's general to all platform where the user has unrestricted access. Mobile OS far a bit better in that respect because the user can be "locked out" of the system (unless they "root" their device) but it's not perfect. But usually, that doesn't matter: hard-coded passwords are never used in properly secure applications in the first place and elements that must be protected is usually separated from the users in some way (T-tier architecture, for instance).
    – Stephane
    Commented Jan 7, 2016 at 10:00

You must log in to answer this question.

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