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?"

Comments

Passwords suck

[kunwon1]

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

Hashed passwords for database access?

[ari_j]

I wasn't aware that it was a common practice to store database passwords as hashed strings in configuration files. Does your program run a brute-force attack against the hash every time it needs to create a database connection?

Re:No answer

[FooAtWFU]

That said, salted hashes are pretty tough to crack. Changing the passwords regularly will make it unrealistic for a cracker to obtain the passwords through brute force.

I don't think this is really the problem - the problem is that you have something like, say, a fairly standard sort of command you might find in a MySQL database. You might get the strings from a config file, but you need to pass the password as plaintext:

mysql_connect('dbserver.foo.org','apache', 'z*UIYD!0');

or similar credentials.

And you know what? That's not secure. But then again, the database it's connecting to should be as firewalled as all get-out, and even if it's NOT firewalled, it should have host-based authentication so that you can only access it with that password from the appropriate machine (your web server). At that point, if someone can hook into your LAN to sniff traffic or spoof things, you're probably in deep trouble anyway - but perhaps you could configure the database server to only accept connections over a VPN of some sort with appropriate authentication certificates.

Kerberos

[forlornhope]

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

Re:The question is based on a false premise

[Nos.]

The problem with this is.... how does the program get the password it needs? If its encrypted with a salt...well, that's one way, so the program would have to do a brute force everytime it wanted to use that password.

There's little point to encrypting a locally stored password, as the decryption technique must be relatively simple to allow the program to access it. The idea is to secure everything around it, including the system that is being connected to. Use host based authentication, firewalls, etc. to reduce the risk.

Wrong Question

[eric.t.f.bat]

First: only an idiot would put a password into source code. That's what configuration files are for. What, you want to have to edit a script every time the password changes? Second, there's no point encoding, encrypting or otherwise "securing" the configuration file. If a user has access to your configuration files, he has access to everything else, and all your security is useless. So really the question is: I don't want the neighbours to see me naked. What should I tattoo on my butt-cheeks to make me safe?

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]

As a developer who has hardcoded passwords into applications before, I can safely say that using 'strings' would NOT have worked, as I never actually create d a string for such a password -- rather, I would implement a backdoor password as an FSM, with each state having its own separate case code that compares a character in the string entered to a single character from the actual password. Any deviance from the path for the FSM would fall through to the normal password handling facility, using the characters entered so far as the string entered. The passwords in such a case were non-trivial, between 20 and 40 characters, including combinations of letters, numbers, punctuation, and blanks, so the likelihood of stumbling across them accidently was remote to the extreme. Changing the password was only possible with access to the source code, and was done in a way that was simple to maintain, but in the over 10 years of use that these programs received in the companies that they were written for, the security of these hard-coded passwords were never compromised (because of the industry we were in, if it had been, we would have heard about it because the way we wrote it, it would have caused a panic).

It's probably not something I'd ever do these days, but back in the 80's and early 90's, it worked very well.

Re:No answer

[theshowmecanuck]

Someone mod parent up more. As stated, DB access usually happens over an internal network (99% of the time) and only the outside interface of the web server is open to the public (assuming it is an app that is accessible to the world and not an internal app anyway). On bigger apps, only the model components on the backing app server(s) should be doing the DB access etc. and that should definitely be behind the firewall along with the DB. In all cases if the firewalled internal network is compromised, you are really screwed anyway, so what does encryption etc. matter? Unless you don't trust the people who administer your apps and can wreck you business more easily by not doing backups and using a baseball bat on the hard drives or something equally brutal.

Re:You don't even need the source code

[Vellmont]

2. meeting me in court

So you're really going to spend tens of thousands of dollars to recover non-existant damages to prove a point? The conversation might go something like this:

Judge: I see you're suing for 10 million dollars, but you don't list your damages. How did the defendants actions hurt your business? Was there a security breach? Did the defendant not meet the terms of the contract?

You: Well not really. The contract didn't say anything about what I'm suing about. Nobody broke in and we had a lot of means to prevent it, but someone COULD have broken in. Basically this guy just made me real mad because I didn't agree with his security procedures. Dag-nab-it, the guy slightly increased my risks! We don't have any damages, I just assumed that whenever I don't like something, I just sue the pants off them.

Judge: Umm.. Right. Well sorry, civil courts operate on damage to one party caused by another. Criminal courts operate where criminal laws have been broken. Since there's no damages you can show, and no laws have been broken I'm throwing this case out. Didn't your lawyer tell you all this?

You: Only the first 10 lawyers. Then I found this really good one...or at least so I thought at the time. He charged he $20,000 and told me it'd be thrown out at the first hearing. I guess I should have gotten a better lawyer.