How not to store plaintext passwords?

October 8, 2009 9:56 AM

Best practices for storing OracleDB/mysql/ldap/smtp/etc... system passwords for enterprise application integration use?

I'm working with a vendor who currently is storing passwords in plain text in configuration files.

If you've ever configured Wordpress you are familiar with how your mysql password gets placed in plain text in the wp-config.php file.
This vendor is doing a similar thing for mysql, ldap, smtp, etc...

This has made some people uncomfortable.

I'd like some suggestions for best practices to minimize the use of passwords in plaintext (or trivially encoded text) in text configuration files.

These passwords are being used to drive external databases, ldap auth, smtp sending, etc...

Their Java / Tomcat application is expected to be running 24/7 as a Server. This particular instance will be on Windows Server 2003 though Linux is also supported.

It would be nice if it would be possible to have unattended restarting of the application without a user having to enter in a master password, but if that is the only solution we may be comfortable with it.

Some background:

The application uses LDAP to authenticate users (and hence has the LDAP system password in a configuration file)

The application stores its data in a SQL database (Oracle in this case, though they also support mysql. We have to stay on Oracle)

The application sends mail using SMTP

Thanks.

posted by bottlebrushtree to computers & internet (9 answers total)

Obviously, you should make sure to set filesystem permissions on the file(s) containing the passwords such that only the user the app runs as can read them. Also, back up your data so that if the database is compromised you can restore.

You can't really have non-plaintext (i.e., encrypted) passwords together with unattended restart. Off the top of my head, the closest you could get would be to encrypt the passwords the app uses and have the app decrypt the passwords to use them. However, this 'solution' would not deter an attacker capable of extracting the decryption key from the application code.
posted by axiom at 10:08 AM on October 8, 2009

Storing passwords in plain text is fine, as long as the filesystem permissions are set appropriately for that file.
posted by odinsdream at 10:15 AM on October 8, 2009

I understand your fear but file and server access permissions are the generally accepted methods for securing these files.

The basic idea is that if someone has command line access to your server where they can view these files then you're hosed anyway, so the right way to secure these passwords is by securing the access to the server and files.
posted by bitdamaged at 10:17 AM on October 8, 2009

One thing that jumps out at me is that the LDAP authentication is done with the LDAP system password. Generally, in cases like this, I create accounts with just enough information to do the task at hand. So if an app needs to lookup a user's department from ldap, the app uses a login that can just bind and do simple lookups. If it needs to authenticate against ldap, it should use the credentials passed to it by the user and attempt to bind to the ldap server. At no point should the app know system level passwords for the ldap server.

The same goes for all the other requirements. Define the bare minimum needs and make a user account on that required service that has just enough rights to get the job done.
posted by advicepig at 10:44 AM on October 8, 2009

Storing passwords as cleartext is NOT fine. Never has been, never will be. It's common but I don't think that is a good excuse. File permissions are insufficient since people often share passwords across domains and you can't trust everyone who has legitimate access to the password database. What's really annoying is that proper one way hash & salt is not complex. Doing it cleartext is just lazy & stupid.

The traditional unix way to store passwords was to store them encrypted via a one-way hash with a salt. See here or here.
posted by chairface at 11:50 AM on October 8, 2009

Chairface, since the system needs to interact with remote systems, I don't think the one-way hash with salt will work, since they need to pass credentials to a remote system as opposed to check an entered password.
posted by bottlebrushtree at 12:02 PM on October 8, 2009

What I have done in the past:

- Encrypt file containing plaintext passwords using blowfish with a master key

- Write a tool to initialize service that takes the master password, decrypts the file, and stores obfuscated versions of the passwords in a protected shared memory segment.

- Have applications that need to connect to database server read from shared memory segment.

- Store and distribute master key using GPG encryption.

Obviously services won't come up on their own after a reboot. Also be aware that this is essentially obfuscation, anyone that understands the code and has access to the account owning the semaphore can retrieve it the same way the application does. There is no way around this if you think about it. It's the same reason there is no DRM that's unbreakable.

What it does allow you to do is have many different passwords for various services stored in one file (which you can safely put in version control), but only need to remember a single password to get everything working.



> The traditional unix way to store passwords was to store them encrypted via a one-way hash with a salt

Yes, for user end-point authentication. Mysql does, indeed, store its passwords as a one-way hash. However his applications need to know this password to provide it, and it has to go somewhere. Whether it's in memory, on the filesystem, it's plaintext. It has to be. You can obfuscate it to hell and back, but at the end of the day the application needs to figure out how to send the password to the service it's trying to connect to.

The upshot is you need to rely on host security. If you don't have reliable host security, you have much, much bigger problems.
posted by cj_ at 12:41 PM on October 8, 2009

Storing passwords as cleartext is NOT fine. Never has been, never will be.

For reference, you can check out the Cathedral and The Bazaar. It's only not fine if your system is already vulnerable. Reasons your system may be vulnerable include sharing accounts, having accounts with too many rights, and so on.

Anything less is, as cj_ correctly points out, security through obscurity. The system is going to use the password in clear-text at some point, even if it's jumping through hoops to do so.
posted by odinsdream at 12:50 PM on October 8, 2009

Well, you could use cryptographic authentication (SSL+client certs, ssh identities, Kerberos), with the client's secret(s) stored in a hardware module from which they can be used but not extracted (USB crypto token, smartcard, etc). This is an utter pain in the ass to set up but can reduce the amount of damage someone can do once they break in to the system.

In the final analysis, remember, anyone who can break in to the machine can (theoretically) subvert the running application and make it issue requests using whatever access it has. The best you can do is:

• Minimize the access that the applications have, like advicepig says. Don't give something an LDAP admin password if all it needs to do is look up someone's email address in the directory.
• Make it easy for you to revoke the access that it has. This means, don't share passwords/keys/tokens between this app and anything that is independent from it. If/when the machine is compromised, you should be able to quickly revoke all its passwords without harming other systems. You should get in the habit of doing that yearly regardless.
• If you're really worried, consider the hardware-module approach I mentioned above. It's probably not worth it, though.

posted by hattifattener at 2:08 PM on October 8, 2009