geronimo-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aman Nanner/MxI Technologies <>
Subject Re: Plaintext passwords in Geronimo plans and config files
Date Thu, 22 Feb 2007 17:23:44 GMT

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.

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

> 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 RAR
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).

> 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.


* 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