geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <>
Subject Re: Obscuring passwords in new ways
Date Sat, 15 Sep 2007 15:01:28 GMT

On Sep 15, 2007, at 10:24 AM, Vamsavardhana Reddy wrote:

> David,
> Thank you for initiating this discussion and also implementing a  
> quick solution too.  Matt asked if I could start a discussion on  
> this.  I said "yes" and then went in to a long sleep mode :(.  Let  
> me get to business (before I go to sleep again).
> More inline...
> On 9/15/07, David Jencks <> wrote:
> Periodically users show up who want their passwords obscured in new
> ways that allow their systems to break by removing the key used to
> obscure them :-)  (how's that for a biased view of the situation :-)
> I have to accept that I share your PoV.
> They don't like SimpleEncryption because the key is hardcoded and
> thus the same for all geronimo instances.
> See GERONIMO-2925
> I've implemented something for this request that allows you to
> register "encryptors" with the EncryptionManager.  By default you get
> the current SimpleEncryption which uses AES with a hardcoded key.
> There's also a ConfiguredEncryption gbean that will generate and save
> a key if not present or use a saved one.
> You can register any number of Encryption instances with
> EncrptionManager but only the first one you register will be used for
> encryption.  Others might be used for decryption.
> If you try to encrypt a string that is already encrypted under a
> different registered Encryption instance it will decrypt using the
> old Encryption and re-encrypt using the registered Encryption.  For
> instance the properties file login module used to use {Standard} as
> the prefix instead of {Simple} so I registered the SimpleEncryption
> instance under both prefixes: the property files are re-encrypted
> with the {Simple} prefix.
> Is this supposed to substitute for  "changing the key"?

Not really, more for changing to a new encryption type from the  
Simple default.  If you start the server up everything gets encrypted  
with SimpleEncryption: it would be nice to support at least  
installing a new Encryption later, which is pretty much what is now  
supported.  If you are careful you can change again.  One question I  
have is whether the current behavior of "first explicitly installed  
Encryption is the method used" or "last explicitly installed  
Encryption is the method used" is a better policy.  I lean towards  
"first" because then a user program can't change it as easily.
> If you want to use the ConfiguredEncryption you can add this to
> config.xml under rmi-naming module:
> <gbean name="org.apache.geronimo.configs/rmi-naming/2.1-SNAPSHOT/car?
> name=ConfiguredEncryption,j2eeType=GBean"
> gbeanInfo="org.apache.geronimo.system.util.ConfiguredEncryption">
> <attribute name="path">var/security/ConfiguredSecretKey.ser</ 
> attribute>
> <reference name="ServerInfo"><pattern><name>ServerInfo</name></
> pattern></reference>
> </gbean>
> Does it have  to be a file under the server installation  
> directory?  At the same time, I don't know if it really matters.

No, if you supply an absolute path ServerInfo will "resolve" it to  
> I haven't tried this with app clients yet but I assume that adding
> this gbean to client would work.
> I'd appreciate review on this both for the idea of pluggable
> Encryption and even more for my use of crypto which I am definitely
> not an expert in.
> thanks
> david jencks
> 1.  The changed attributes are stored in config.xml.  These will  
> get overwritten when a new encryptor is used, which is as we  
> wanted.  What about the attributes that are in config.ser objects  
> which are never changed?  Do we have to protect these files too?   
> Any default passwords in our server distributions that live in  
> these config.sers's may not be of much concern as we expect the  
> users to change the default passwords anyway (no point encrypting  
> something that is well-known :o).  I am referring to config.ser's  
> created upon deploying new configurations.

I think we should advise users to override passwords that may be  
stored in config.ser in config.xml.  We need to figure out how to do  
this easily :-)
> 2.  If a deployment plan is part of the archive being deployed, the  
> plan file will exist in the repository when the archive is  
> extracted to the configuration's directory.  Should we get rid of  
> these deployment plans once the archive is distributed as they may  
> contain passwords in clear text?

I think we should preserve the source plans for reference and advise  
people not to put sensitive passwords in them.
> There may be other concerns, which I will put down as they come.   
> We may have to come up with some guidelines, make it clear what the  
> users can expect from G and how to protect their server.
> Vamsi
> PS:  May be we should create a wiki page to capture this discussion.

At this point I think we should create the wiki page after we decide  
what to do.

Did you have a chance to look at whether I am doing something stupid  
with the crypto stuff, in particular generating the secret key?

david jencks

View raw message