We’re building an application that needs to log into a website using built-in credentials. It’s not optimal to say the least, but we’re stuck with “knowing” the username and password beforehand (hence stick them into the application somehow) and can not rely on runtime user information.
So I went through this stack overflow article which basically represents my case and the answer seems to indicate that best possible approach is to at least encrypt the password with a known key and to store this key in the application in an obfuscated way. My follow up question now is: How do I best obfuscate this key so that it isn’t visible in a file dump of the executable? Are there best practices for that as well?
You need to be aware of the caveats in the comments already given, and experience has shown that even strong obfuscation of built-in keys is not safe if an application is widely distributed and there is something of value to gain from cracking it.
That said, if you’re OK with credentials being present in the running application where a debugger may find them, a possible mechanism would be to code a computation that returns a fixed result (for example by hashing the concatenation of the application name and an unchanging part of some help text), and use this as the key to decrypt the actual credentials, which may be stored in encrypted form within the executable or in a configuration file.
I’m currently using such a scheme to store database credentials in an internal-use application. Distribution of this application is strictly limited to in-house users, and most users use it on locked-down terminal servers where debugging or reverse engineering tools are not available and can’t be installed by users.
Obviously this isn’t ideal, but you know that already. If you’re not sure about their security you’ll at least want them to have their own set of credentials so that you can invalidate them if they become compromised so that it doesn’t put your servers at risk.
That said a slightly alternate approach you might want to consider is using the OS’s native credential storage system. Windows for example has CredRead* functions that lock credentials to a user account. During the install process you could have them enter the user/pass and store it there (or possibly have the installer do it automatically), making it available to the windows user account the server is running under. It would not be accessible outside of that account.