Keeping Passwords Embedded In Code Secure?

JPyObjC Dude asks: "When designing any system that requires automated privileged access to databases or services, developers often rely on hard coding (embedding) passwords within the source code. This is obviously a bad practice as the password is then made available to anybody who has access to the source code (eg. software source control). Putting the passwords in configuration files is another practice, but it is still quite insecure as cracking hashed passwords from a text file is a trivial exercise. What do you do to manage your application passwords so that your system can run completely automated and yet make it difficult for hackers to get their hands on this precious information?"

Passwords suck

[kunwon1]

Use SSL with certificates. It's more easily automated and just about anything worth running has the option.

Kerberos

[forlornhope]

Kerberos was built for just this situation. Read up on it. I think its even available as Active Directory for MS.

Re:Public-key crypto?

[strider44]

Nope, still won't work against a cracker. This is just another form of DRM and DRM is fundamentally flawed. (If you don't believe me show me a major game that hasn't yet been cracked.)

In short, if a cracker has full access of a program or system and the system has access to the passwords (even if it does some fiddling around before revealing the passwords) then the cracker has full access to the passwords. There's no way to protect against that except by not allowing any access to the passwords (by just not posting the files that the passwords are in) or by not having the passwords in the program at all and having it so the user must type them in. Anything more are delaying tactics and do not give a high level of security, just some level of obfuscation...

Can't be done, no way, no how.

[swillden]

First, let me dispose of one issue:

This is obviously a bad practice as the password is then made available to anybody who has access to the source code (eg. software source control).

It's much, much worse than that, because the password is also available to anybody who has access to the binary. "man strings".

Others have suggested various options, but absolutely none of them work.

• "Shrouding" passwords, whether in code or in config files. Don't make me laugh. No matter how you try to obfuscate the password, all of the code needed to recover the password (or the hash, or whatever needs to be submitted to perform the authentication) is there, just waiting to be dug out. You can make it obscure, but you can't make it secure.
• Public key authentication? Bzzzzt. The private key has to be present on the file system, where an attacker can grab it. "So, encrypt it!", I hear. Umm, you have to have the passphrase to decrypt it somewhere in your code or config files.
• Kerberos? You still have to have some mechanism for authenticating to the ticket-granting server, and if the attacker can get that, then he can also authenticate, just like you.
• Host security module? TPM with auth credentials bound? Well, these do protect against some attacks, but if the attacker can own the server, he can use the hardware token to do the authentication for him, just as though he were the server. These do prevent him from being able to take advantage of physical access to the machine to reboot it with another OS and then dig through the drive contents. Assuming the system is configured tightly enough that booting a different configuration is the only way in, then a TCPA TPM actually does the job. This of course, requires that the system have no exploitable security holes (ha!).

The bottom line is: If the machine has all of the information needed to perform the authentication without human intervention, then an attacker who gains control of that machine has all of the information needed to perform the authentication. Period. No getting around it. The best you can do is limit the damage in the case where the attacker has only partial access.

What is that best? For a network-accessible machine, do the following:

• Lock down the system as tightly as possible. Standard system security stuff, but be as hardcore about it as you can.
• Use an authentication protocol that can be performed between a highly-secure HSM and the remote resource, using the main machine as a passthrough only.
• Secure the HSM with a password or authentication key, so that the HSM won't do its authentication job without first being authorized.
• Use a TPM to bind the HSM authentication data to the system state. This will make patches a PITA, but we're going for maximum security here, so that's okay.
• Put the whole assemblage in a secure facility, ensuring (hopefully) that no potential attacker gains physical access to the machine.

That's a lot of work, and it's still not completely secure. Luckily, very little needs even that level of security. Oh, and there aren't any OSes available that make good use of a TPM yet, so it's not really possible.

For most systems, what I'd really recommend is: Put the auth credentials in plaintext in a config file and limit access to that file to the bare minimum. If you have Mandatory Access Controls (e.g. SELinux), configure them to allow only the server process to read that file. Then, lock the whole system down as tightly as possible (within existing constraints). Ensure that a bare minimum number of people have logins on the machine, and that they all have minimum permissions, firewall it as completely as possible, and keep it up to date on security patches. Finally, put it in a locked room and tightly control physical access to it.

Of course, even this reduced-security approach is too onerous in many cases, so you have to make compromises. That's where a good understanding of security and plenty of hard thinking about what compromises can be made come in.

There ain't no silver bullet.

Re:Can't be done, no way, no how.

[swillden]

Responding to myself... Uh oh.

It occurs to me that I may be answering the wrong question. If the assumption is that the attacker won't have access to the server, but may have access to the development team's source code, then the answer is simple: put the password in a config file that the developers don't have access to.

Re:You don't even need the source code

[mark-t]

The danger of it ever having become publicly known that there was a backdoor was negligible... the number of companies that we wrote software for was countable on one hand, and being vertical market software, there was no danger of it being used elsewhere.