-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Filip,
On 4/23/12 1:47 PM, Filip Hanik Mailing Lists wrote: >> http://wiki.apache.org/tomcat/FAQ/Password >> >> >> In short, no. >> >> Encrypting your database, database user, and database password >> buys you virtually (and most people would say actually) nothing. > > "virtually nothing" is the opposite of what I would call it. What > about compliance, this is HUGE for companies, and not to be > discarded as an unimportant requirement While it is viewed as an important requirement, there are really only 3 possible ways to fulfill it: 1. Enter the password at the command-prompt as the service starts (or allow such credentials to be provided after start-up in some way). This is the only one of these 3 possibilities that actually offers any real security. Unfortunately, it's an operational impossibility. Apache httpd has the same problem with server keys. See #3 for how that is (stupidly and commonly) handled. 2. Use a de-obfuscator to recover your plaintext credentials from some non-plain-text input (your suggestion, Filip). This just moves the problem somewhere else. So, your server.xml (or, better, context.xml) is clean but your context.xml.secret-stuff is suddenly not clean because it contains the password for the password. Sure, you pass an audit that is looking for something very specific, but you don't buy yourself any real security. It's like requiring a really good lock on a door when the window next to the door is always wide open. Yep, that's a great-lookin' lock you got there... you're definitely protected. 3. Remove the password completely. That is, use a password-less credential. Sounds completely stupid, right? Well, having a plaintext password is essentially the same thing, since who would guess that the password is nothing, right? You'd have to have access to the server.xml (or context.xml) to know that (unless you just /tried/ it, of course). Your database ought to be locked-down enough that you can't connect from just anywhere, so having remove access to the server that connects to the database is just as good as having access to the database, right? This is how Apache httpd recommends that you *don't* set up your web server's certificate keys. In my experience, *everybody* does this: you make a password-less key and use that to start your server. Just make sure you set permissions appropriately. This is also not secure, but it's very practical: if someone has access to your box, the game is over anyway. Having a trivially-discovered password is as good as having no password. > http://tomcat.markmail.org/thread/wmdu4e52y2msjzal VMWare's documentation shows you how to do #2 above either with some other credential (good luck protecting that one any better) or with no credential (in the example of using Base64 encoding). - From a requirements-complance perspective, yes, there's some utility to not having a cleartext password in your configuration file. An honest risk analysis will show that the case before and after such obfuscation is identical: you are no more protected than when you started. It's actually worse, because you *think* you are somehow magically protected. The security checkboxes have all been checked. We're secure, right? Drinks all around. - -chris -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+VtIIACgkQ9CaO5/Lv0PB1ggCgtGxUz183qITETmSyZS7yW2JU nDoAoJSFWQJvY3B5TGeJlAolohb0rxOg =LfY/ -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
