geronimo-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <>
Subject Re: Plaintext passwords in Geronimo plans and config files
Date Thu, 22 Feb 2007 17:45:21 GMT

On Feb 22, 2007, at 9:23 AM, Aman Nanner/MxI Technologies wrote:

> David Jencks <> wrote on 02-22-2007 12:01:11 PM:
>> On Feb 22, 2007, at 6:12 AM, Aman Nanner/MxI Technologies wrote:
>>> Hi,
>>> I have noticed that passwords in plans and configuration files in
>>> Geronimo
>>> (1.2-beta) are not encrypted by the server, and remain in
>>> plaintext.  For
>>> example, passwords in:
>>> 1) Datasource connector plans
>>> 2) ActiveMQ connector plans
>>> 3) TomcatWebSSL Keystore passwords
>>> 4) Geronimo properties realm passwords
>>> Having these plaintext passwords in these configuration files  
>>> pose an
>>> inherent security risk that would prevent us from deploying
>>> Geronimo out to
>>> customer sites.  Are there any plans to have all these passwords
>>> encrypted?
>> 1-3 of these are in module plans, which are unneeded after the module
>> has been deployed into  a car file.  So, don't distribute the plans
>> but the car files.
> That's an interesting idea, but we need to have the module plans
> distributed as part of the EAR, as the customer will need to  
> redeploy our
> application if we provide them with custom software integration  
> pieces at a
> later point in time.  Currently with our customers that use JBoss or
> Weblogic, we provide scripts as part of our distribution that will  
> unpack
> an EAR, add new custom EJB jars or WARs, and redeploy the EAR.  We  
> would
> like to do the same with Geronimo.

You probably want to use similar methods for all the app servers you  
support, but for geronimo you might be able to package the additional  
pieces as plugins and distribute them in that form, which would once  
again eliminate the need to distribute plans.

> What we could do, after deployment of our EAR, is encrypt the  
> passwords in
> the plans ourselves using a script.  When the customer needs to  
> redeploy
> the EAR, we could have a script that would decrypt the passwords into
> plaintext, redeploy the EAR, and then re-encrypt the passwords after
> deployment.

Another approach for the db/jms connectors that I like although I'm  
not sure if its completely tested is to leave out the user/pw from  
the plans and use Subject based authentication.  With this approach  
you'd add a login module to the security realm that would insert  
appropriate UserPassword credentials into the subject for each db/jms  
you need to use.  When you need a connection to a db/jms these  
credentials would be used instead of those from the db/jms connector  

I think this is plausible right now for users who are logged in but  
I'm not sure it would work for default subjects for unauthenticated  
>> For (4), I'd suggest you use a non-toy authentication method such as
>> ldap.  Properties file based authentication is mainly intended for
>> experimentation.
> We currently have our own custom realm that uses a DB for  
> authentication.
> This custom realm is application-scoped within our EAR.  Probably what
> we'll do is make the custom realm system-scoped, and use it in  
> cases where
> the properties realm was being used.
>> You can probably figure out how to extract passwords from the car
>> files if you work hard enough.  However, if you think this is a
>> problem I'd like to remind you that security against someone with
>> physical access to a machine or complete file system access is pretty
>> much impossible: look at the recent HDDVD crack.  In other words, if
>> you distribute software to customer machines, you should assume that
>> if they really want to they can extract any passwords you try to hide
>> in the software.
> There are still safeguards that are used in the event physical  
> access is
> breached.  For example, passwords are usually hashed using SHA-1 or  
> MD5
> algorithm when stored in a file or database.  In this event,  
> someone who
> has physical access to the machine (be it an intruder or the database
> administrator) cannot determine what any individual's password is,  
> since it
> is one-way hashed.
> Of course, one-way hashes are useless for the deployment plans  
> unless the
> hashes can be provided to the underlying system.  For example, if  
> ActiveMQ
> accepted password hashes, then the passwords could be hashed in the  
> plan, and these hashes could be provided to ActiveMQ.  Otherwise, a
> reversible encryption algorithm would have to be used to encrypt the
> passwords (so that they could be decrypted before being sent to the
> underlying system).

Well, if say AMQ accepted hashes, that just means that the passwords  
are less likely to be remembered by a human.... the hashed value has  
become a password.
>> I've wondered if it would be appropriate to provide a mode whereby
>> you need a password to start geronimo or you supply a command line
>> password to unlock the keystores on startup, but haven't got much
>> beyond wondering if it would actually provide any additional security
>> beyond that available on a properly secured server.
> From our experience, there are many customers that freak out if  
> they see
> plaintext passwords ANYWHERE on a system, even if it is secured.  I do
> realize your point about properly securing the server, but there exist
> certain security standards (EAL, for example) that likely would  
> require
> visible passwords to be encrypted or hashed.

I think this is definitely a topic that needs further consideration.   
My preference is that we come up with a solution that actually  
provides some level of security rather than relying on obscurity and  
as a result my bias is to object to schemes that simply obscure  
information.  They could still be useful and a good idea :-)

david jencks

> Thanks,
> Aman
> ______________________________________________________________________ 
> ____________
> * This message is intended only for the use of the individual or  
> entity to which it is addressed, and may contain information that  
> is privileged, confidential and exempt from disclosure under  
> applicable law. Unless you are the addressee (or authorized to  
> receive for the addressee), you may not use, copy or disclose the  
> message or any information contained in the message. If you have  
> received this message in error, please advise the sender by reply e- 
> mail , and delete the message, or call (collect) 001 613 747 4698. *

View raw message