tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Schultz <>
Subject Re: dbcp datasource encryption
Date Mon, 23 Apr 2012 19:58:58 GMT
Hash: SHA1


On 4/23/12 1:47 PM, Filip Hanik Mailing Lists wrote:
>> 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.


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
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools -
Comment: Using GnuPG with Mozilla -


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message