geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Vamsavardhana Reddy" <c1vams...@gmail.com>
Subject Re: Obscuring passwords in new ways
Date Sat, 15 Sep 2007 14:24:38 GMT
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 <david_jencks@yahoo.com> 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"?

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.

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

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.

Mime
View raw message