How to best obfuscate a built-in key in an application?

Question

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 StackOverflow article which basically represents my case and the answer seems to indicate that the best possible approach is to at least encrypt the password with a known key and 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?

Answer 1

Hard-coded credentials are considered a vulnerability. Cisco gets caught time and time again, and have to issue a fix to remove them every time.

No matter how many layers of obfuscation you employ, the credentials must be deobfuscated before being used, so an attacker can grab the plaintext of the credential by using debuggers or disassemblers. You cannot stop this attack, you can only delay it.

Other downside of storing the credentials on the executable is that isn't easy to change the password: you will have to generate another executable and have the user download and replace the old one. This can lead to attackers sending an executable to the user by email or social network claiming to be you and offering a new one.

If all your clients use the same password this will be even worse: if one user leaks the password, you will have to revoke the credentials for every single client, and issue a new executable for everyone.

Every password should be unique and easy to replace. You can generate a key, store it on some file, and send the password to the user out of band. This way the user can replace the password if it gets compromised, you don't need to generate another executable, and every user gets a different password.

Answer 2

log into a website using built-in credentials.

Going over HTTP(S) is always going to be an enormous hurdle to any obfuscation, especially if the website you are logging into has a regular username/password field that takes a POST. That traffic is not intended to be hidden from the computer owner who can easily supply their own trusted CA files or try any number of other snoopy things.

It may be the username and password are not actually that essential to security, but if they are you need to run a proxy style service. That would absolutely hide the credentials from the client and would also allow them to only perform specific actions with the authorization granted by the credentials.

Answer 3

Don't bother with the app - check the data instead (if you need to)

Really, the only use case where you'd care about this kind of login is if the server has to trust the data produced by the app - and by extension, has to trust the app to be your app and not someone else's hack attempt. As has been demonstrated countless times, this is literally impossible. However you obfuscate it, someone will break it, given enough incentive (or just a lot of free time and boredom).

This isn't a new problem though. A perfect example of this kind of problem would be aim-bots in online gaming; or perhaps the regularly-reported data sent back to Pokemon Go about the number of steps you've taken. It's not possible to prevent people hacking these systems, because ultimately the data has to get back somehow, and there are incentives in gameplay for people who do. The solution taken by games designers is to check what comes back from the app and see whether it's valid. If moves are too straight and accurate to be human, it's probably an aim-bot. If your number of steps coming back to Pokemon Go is unachievable within that time at the maximum walking speed, it'll be rejected. Clearly this checking process can be complex, but this is one way you can solve it.

But then you also have to ask - does it really matter? My company makes industrial microscopy equipment. We simply don't care about secure connections between our controller boxes and apps on a controlling PC. Sure, a suitably dedicated person could spend some time and find the secret commands we use to calibrate the system. But the result then would be a system that no longer works properly, and we certainly wouldn't repair/recalibrate the system under warranty. There isn't a benefit to the user to do this, and it'd cost us time and money for something which isn't a benefit. So we don't bother.

Or quit now before the lawyers find you

If it does matter that this data is held securely - in particular, if it's about bank details, government files, or personal details under GDPR in Europe, COPPA in the US, or anything similar - then be afraid. Very afraid. The most likely potential consequence is "merely" your company being sued for every penny it has, so forget about that last cheque. That's the best outcome. If you play f***-around-and-find-out with bank details or government files though, that's serious jail time. And depending on where you're working, if you're the senior engineer then you may have to sign off personally on the work, which leaves you personally liable and not just the company.

If your management are suggesting this, your only option is to refuse. Your bosses can only give you instructions to carry out work that's legal, after all. If that doesn't cut it, leave now. (And if you're feeling so inclined, consider whistleblowing.)

Answer 4

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?

There is a system where you encrypt your key using AES, and the application decrypts it again. However, the application doesn't have a general-purpose AES algorithm and they key in a string, but it has the key compiled into the algorithm. This way, it is pretty hard to determine the AES key.

Unfortunately, I cannot currently find the name of this mechanism or the product that offers this. White-box cryptography

Answer 5

Security becomes more challenging in this area, but this is a legitimate question. You should look very carefully at the scenario to see whether additional user or device authentication are possible; and perhaps provide more detail in the question.

1. Ideally you authenticate users (having had them register first) and login individually with user credentials. Any bad actors can then be locked out on an individual basis.

2. If you can't register users, you should definitely look into registering devices. Obtain a unique identifier from the device on first startup, register that with the server to obtain a permanent key, require admin approval of the device (eg. by model & serial number) and use the permanent key to authenticate when connecting.

3. Less preferably, you can register groups (eg. corporate installs) & distribute a unique secret to them. This can be a license key to be pasted into a dialog, or a file placed in the install directory. Software compliance works better when you are also notified of which devices are running it.

4. Really you want to register and authenticate either users, or devices. You will find yourself in silly situations if you do not.

5. If you have nothing unique locally, consider generating a nonce locally on first use & registering that with the server to get a secret key.

6. Lastly, you can obfuscate secrets within an application binary; this will block unskilled actors but not a reverse engineer/ cracker. The approach here is to combine stored factors with computation in a non-obvious way; this prevents actors from reading your secrets directly from the binary. (Though unless you are skilled, they may be readable from a memory dump.)

Approaches to obfuscate secrets within the application binary:

• Combine stored factors from more than one place; eg. one key from the binary, one key from an install license file, perhaps an initial vector elsewhere in the binary or constants in instructions.
• If you can add in device- or user-specific factors, these will make the secret far stronger and prevent a breakage being used to attack other devices.
• Use standard cryptographic primitives (eg. SHA256 hash).
• Combine parts by hashing; using loops and a non-trivial structure of parts. Eg. several of this keypart, a few of that keypart, a constant text from somewhere else, hash in some instruction constants etc; perhaps spread this over two levels of looping with some parts in the inner, some in the outer loop. Use thousands of inner loop iterations total (say 10k to 100k).

The above approach will prevent a secret key from being readable from the binary or filesystem. However the complete key will still be formed in memory; and potentially readable if an attacker has access to a memory dump.