1

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?

11
  • There are commercial "exe packer" tools which can do this, as well as various "DRM" solutions; it's how game developers and others do anti-cheating and licensing control.
    – pjc50
    Oct 26, 2023 at 9:23
  • @pjc50 Are there also non commercial conan-ready libraries that you know of?
    – glades
    Oct 26, 2023 at 9:35
  • How about using a key that looks like the result of compiling some code? Just hide it in plain sight. Oct 26, 2023 at 9:59
  • @BartvanIngenSchenau That sounds like a plan. This + openssl to encrypt the password is by now my best bet.
    – glades
    Oct 26, 2023 at 10:01
  • 3
    You can never truly trust something that's run on someone else's machine and someone else's network. They could be capturing the communication, or decompiling your application or... A safer bet would be to openly use credentials that the user is aware of, as this wouldn't need to be kept a secret. That being said, it's unclear exactly what your reasoning is for needing these hardcoded credentials, making it hard to understand exactly how and if this is an XY problem and what could be a better solution.
    – Flater
    Oct 26, 2023 at 10:22

2 Answers 2

5

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.

5

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.