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 <[EMAIL PROTECTED]> 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
itself.
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?
thanks!
david jencks
