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 (795332)]

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

Re:

[xenocide2 (231786)]

But what do you do when you need to revoke the cert? The problem is that they want authentication without the rigor of.. authentication.

Re:

[swillden (191260)]

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

Makes little difference from a security standpoint, though. If the attacker can get at the file system, then he can read the private key.

Re:

[theshowmecanuck (703852)]

It is kind of moot anyway... if the attacker can get at the file system, they probably can do whatever they want.

Re:

[swillden (191260)]

A CRL is only useful if you know the key has been compromised. I think OCSP is a better solution, anyway.

Re:

[ryanr (30917)]

I don't see how an SSL certificate is going to help here. Since he's talking about authenticating clients, it would be a client certificate, which would have to be embedded in the app, same as a static password.

Hashed passwords for database access?

[ari_j (90255)]

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:

[eluusive (642298)]

That still doesn't make any sense. We're talking about making database connections.

Re:

[Proud like a god (656928)]

For passwords for that program's users, yes it works, but as a stored password to be passed on to another system, like you say, no.

No answer

[Sancho (17056)]

On-disk passwords simply aren't secure. If you need automation, you want to secure the systems as much as possible.

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.

Re:No answer

[FooAtWFU (699187)]

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.

Re:No answer

[theshowmecanuck (703852)]

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.

You can't

[ryanr (30917)]

You can't secure a client-side password without another password to protect it. Which is contrary to what you're trying to accomplish. If you could give a bit more detail about what you're trying to accomplish, we could probably better enumerate the trade-offs.

Public-key crypto?

[FlyByPC (841016)]

IANRAProgrammer, but...

I believe public-key cryptography could do this. Encode the public key (several kilobits, if you're paranoid)? in the source, and have the program use it to authenticate the secret key given by the user. Publish the source code on YouTube for all the good it will do an adversary, right?

Re:

[strider44 (650833)]

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 ju

Re:

[strider44 (650833)]

Apologies - I misinterpreted obviously what you said (I thought that you meant for communicating between processes not someone who is using it actually inputting a password). Actually your idea will work against a cracker and I just made a fool of myself, damn no edit key. It's not the most practical solution since there would be only one password that every user must have and it also won't give automation like the summary wants but it will still work against someone without that password.

The question is based on a false premise

[Ignorant Aardvark (632408)]

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.

This simply isn't true. If salting is used (which is quite commonplace these days), it's pretty much going to be impossible to recover the password from the hash.

Re:

[Nos. (179609)]

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.

Re:

[Proud like a god (656928)]

Does that work? Isn't the salt mean to be kept as secure as a non salted password hash? Otherwise you still know you need to reverse hash(salt+password), just like without salt when you needed to reverse hash(password).

Only by not knowing the salt (i.e. that any password you hash isnt going to match the stored hash unless it happens to be the unknown salt+password) would you be trying the harder task of reversing hash(?????password) into salt+password.

Kerberos

[forlornhope (688722)]

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

Re:

[swillden (191260)]

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

You're right that MS provides a bastardized version of KERBEROS, but wrong that it helps.

In order to get an authentication ticket from the ticket-granting server, you have to authenticate to the ticket-granting server. If the machine can start up completely unattended, that means it has the KERBEROS authentication credentials stored on disk somewhere, which means the attacker can get them, and can then authenticate to the ticket-granting server and get whatever authentication tokens he needs.

Re:

[ryanr (30917)]

Under exactly the right circumstances (i.e. all of your userbase always logs into the domain before running the database client app in question), this pushes the authentication problem to exactly where he wants it. Unfortunately, the original poster hasn't given nearly enough information to tell if Kerberos/AD/any-other-SSO will help his situation.

But as you've indicated, for other situations this won't help.

Permissions

[andy753421 (850820)]

'chown apache:apache database.conf && chmod 600 database.conf' That's good enough for me. Generally I'm not concerned with people accessing the physical hardware in order to bypass permissions, that's another issue entirely.

Re:

[georgewilliamherbert (211790)]

Ever worked anywhere where security concerns meant that the UNIX Admins aren't supposed to have access to the database contents?

It gets much more fun.

Re:

[Proud like a god (656928)]

So as admins do they have access to the database program binary? What happens if they alter it to allow them access or just dump the data elsewhere when launched? Checksums and IDS against ur own admins?

Assume they know the password

[mattfata (1038858)]

The better practice would be to make raw access a non-issue. Don't give the user account the privileges to accomplish anything that wouldn't be possible with the application itself. If you're using some sort of SQL database, consider limiting the permissions on the account to stored procedures that correspond your application's features.

Wrong Question

[eric.t.f.bat (102290)]

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?

Well...

[vga_init (589198)]

If you want to do something quick and dirty without bothering to code in some robust password mechanism (let's say you want to use the same old password every time, hard coded as you say), why not creat a function to generate the static password using deterministic methods? People with access to the source code wil lbe able to spot what you've done, but at least they won't know the password without actually running the code. You could try to obfuscate the function as much as possible and store the generat

Re:

[flonker (526111)]

More along these lines, create a seed password, set it in the source and in the database. Have the application randomly (this is the hard part) change the password in a non deterministic manner, changing it first in a backup config file, then on the database server, then in the main config file. (In case of failure, the admin can copy the password from the backup config file to the main config file.) Possibly have the application rotate the password every so often. This protects the password from someon

Re:

[ryanr (30917)]

People try to do this sort of thing all the time. It's not actually secure, of course, but it makes for some entertainment. If you want some to play with, Google "crackme."

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

[swillden (191260)]

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 (191260)]

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:

[KermodeBear (738243)]

Wrong question or not, your answer was awesome. It confirmed a lot of what I already believed to be true and gave me some new tidbits of information as well. Many thanks. (o:

Re:

[chthon (580889)]

A very good summary of what I found out myself.

I have the same problem, and what I did was just use no password at all, but create different roles for the system.

Our programs have only a certain role in which they can insert or update only certain parts of the database. Really sensitive tasks must always be done by an operator, who has to log in manually.

Unfortunately, we are using mySQL, which is not as rigorous. For update actions the restricted role must also have query capabilities.

I think that by u

What I do...

[GWBasic (900357)]

It's all about managing your risk: This is what I do:

• The password is loaded from a configuration file
• The password (in the configuration file) is encrypted
• The encryption key is stored in a script that's only accessable by a generic system account
• The automated job runs in a system that has to store the password; the stored password is only readable by trusted employees

Is the system 100% secure? No. Is the system secure enough? Yes! The key is risk management; the probability of our system being co

Re:

[Proud like a god (656928)]

Why not cut out the stored encrypted password bit and have the password only stored where those trusted employees can access? Sounds like a simple user/file permission system really.

A simple solution.

[Lethyos (408045)]

I see a lot of elaborate answers, but we all seem to be forgetting something obvious. When the service comes up, have it prompt an administrator for the password then store it in memory. Ultimately this is only obfuscation, but despite passwords getting stored in memory all the time and I think the rate of compromise remains fairly low. At any rate, it is a lot less likely an attacker will find it there than in a plaintext file on the disk. Apache HTTPD and all the MTA services I use do this when using

Re:

[Proud like a god (656928)]

Are you trolling or missing the point? If it is to be an automated system, you can't have the admin manually put in the password each time it starts. So how do you replace that? Having either the program itself read from a config file or even another program supply it doesn't solve the problem of how/where to securely store the password for these methods to work.

Eventually you seem to have to trust root and file permissions that the programs and config files can only be accessed by those you trust to do so,

Some possibilities

[digitalhermit (113459)]

First thing, storing passwords is a bad idea but sometimes cannot be avoided. There are a few things that can be done. None can really prevent someone from dumping the memory contents because, unless you use more sophisticated client/server validation (based on IP, MAC, host auth, etc.), someone with the right privileges can core dump the system or strace the process. Yes, if someone has access to strace a process you probably have bigger issues, but it's conceivable in a DMZ environment where a particular

smart cards

[oohshiny (998054)]

The only secure way on current hardware for automated authentication is not to embed passwords in source code. If you're willing to use extra hardware, your best bet is a smart card.

Encrypted File System and other tricks

[Midnight Warrior (32619)]

Encrypted file systems have a similar problem. They need to decrypt the filesystem for authorized boots or mounts, but need to stay encrypted otherwise. One common trick here is to only make the decryption key available once, at start up, after which it is put into memory, preferable with a small amount of obfuscation to slow down memory walkers. You could then use something like FUSE [freshmeat.net] to mount the encrypted filesystem with your plaintext password.

As other folks have wisely pointed out though, the best posture is to use mandatory access control and restrict access to the configuration file. If you have the privileges, another good practices involves removing all compilers from the machine, firewalling all FTP traffic in or out, firewalling egress (outbound) HTTP traffic (pull in files to process), restrict SSH traffic to pre-defined nodes and enforcing that with a firewall ruleset. Preferably, you'd make all the firewall stuff occur on a separate box. What this does is restrict what tools will be available to an attacker. You can also remove fun programs like strings, ldd, od, *hexedit, and so on. "But I need to modify these tools!" you say. Leave SVN or CVS clients on the node, check your changes into SVN/CVS on your test bed machine, and then just check out the latest stable branch on your exposed machine. Then you get good protection and good configuration management all in one swoop.

Other tricks involve establishing a proxy process or strict limiting what can be done with the compromised username/password. A proxy process might be a setuid C program that only does one thing and accepts no user input. If you must accept user input, be extremely strict (use sscanf on all inputs and limit the size of the buffer accepted) and then have an experienced C developer review your code for improper bounds handling. This proxy process might do things like move files to a read-only directory structure (static web pages in a DMZ), or it might be a CGI script that updates rows in a database. We've actually used the CGI script idea because it a) it a cross-platform way of talking to the database, b) is a good decoupler of otherwise complex code, and c) strongly limits what can be done as an attack. Be careful of the venerable SQL injection attack there though.

A good use of a proxy process might be the transparent mounting/unmounting of an external USB drive, perhaps against a hidden partition on the stick. The drive would have your key. Sure it's obfuscation, but it's complicated enough to decode that it will slow somebody down for a while.

The last trick is to limit what can be accomplished with the username/password that is obtained. We have some processes whose job is to inject data into the database for the backend to all of our tools. That database user is limited to select, insert, and update operations. With Oracle, I could even restrict which specific tables get which privileges.

The best thing to do is to write a document that some folks call the Security Design Document to define your security posture, what you are known to protect against, and where you are vulnerable. Assign a risk mitigation matrix (vulnerability, threat, countermeasure, residual risk) row to each vulnerability. Be honest and then let your manager understand the position you've left them in and try to assign a cost to each countermeasure/mitigation so they can make a decision on what to close or leave open.

You are always going to have vulnerabilities. Everyone does, even the best systems. What makes the difference is those who analyze, understand, and counter that risk in a way that is appropriate to the situation. Direct exposure to the Internet is a situation that should warrant better risk analysis, but rarely does.

No really good solutions

[rlp (11898)]

You've got a machine A on the interior LAN, that needs credentials to access a DB on machine B on the interior LAN. You've got two choices:

1) You can store the credentials somewhere on machine A.
2) The service (typically a Web server) on machine A can run with an account that's either has privileges to access the DB or has privileges to access credentials stored somewhere else to access the DB.

If an intruder gets access to machine A and gets root / admin privileges - then they can gain access to the DB. Obviously, you're first priority is to make sure that this does not happen! Use good firewalls and firewall rules. Make proper use of a DMZ. Check your application for security problems (buffer overflow, SQL injection, etc). Keep up to date on patches. Your second line of defense, is to:

1) Try to insure that an intruder is detected.
2) Make them work for it (access to DB)
3) Have a good audit trail
4) Monitor your network and application

I'll address item #2. Assume that you put the credentials in the configuration file or a separate file on machine A. You should encrypt the credentials (using an encryption application NOT kept on machine A). The key can be hard-coded in the (web) application. If you want, you can use layers of keys(Encrypted key b decodes key in config file. Encrypted key c decodes key b, Encrypted key d ...), but this quickly reaches a point of diminishing returns and can become a maintenance nightmare. You can obfuscate the key or even build it on the fly to make it more difficult to extract it from the application (for binary apps - it helps to strip the symbol table). Use the OS permissions to restrict access to the config / key file and the (web) application. This won't stop a determined intruder, but they'll have to work for access, and it will slow them down.

Re:You don't even need the source code

[mark-t (151149)]

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:

[ryanr (30917)]

You don't think that's actually safe, do you? You've just made it more complicated (aka fun to crack.)

Re:

[mark-t (151149)]

Well, in the environment we were in, it was as safe as the physical security on the building, and as nobody else would have ever had reason to suspect that there was such a backdoor in the first place (we never told anyone until long after the software fell into disuse, and even then it wasn't deemed a security risk by anybody because phsyical access to the computer was necessary to enter the password anyways). In the 12 years that the software was used, we only ever needed to use the backdoor once... and

Re:

[SillyNickName4me (760022)]

and as nobody else would have ever had reason to suspect that there was such a backdoor in the first place (we never told anyone until long after the software fell into disuse, and even then it wasn't deemed a security risk by anybody because phsyical access to the computer was necessary to enter the password anyways)

Excuse me?

Whenever I get apiece of software of which I cannot verify the source, I suspect a backdoor password being there. This is basic security and has been documented at least since the fir

Re:

[mark-t (151149)]

Whenever I get apiece of software of which I cannot verify the source, I suspect a backdoor password being there

Yeah... and...?

I mean, so what if you suspect a backdoor being there, what do you do about it? Not use the software?

This wasn't an option for the companies who contracted us to write the software for them... and no, we didn't tell them about the backdoor. Neither, however, did we ever actually use it except the one time in the 12 years that the software was being used that it was necessa

Re:

[SillyNickName4me (760022)]

I mean, so what if you suspect a backdoor being there, what do you do about it? Not use the software?

Generally spoken, that is indeed the correct answer.

This wasn't an option for the companies who contracted us to write the software for them...

Sure it was, they could have contracted someone else who gave them the possibility to review the source code.

and no, we didn't tell them about the backdoor. Neither, however, did we ever actually use it except the one time in the 12 years that the software was being u

Re:You don't even need the source code

[Vellmont (569020)]

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.

Re:

[mark-t (151149)]

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.