Obscuring passwords in new ways

[David Jencks <da...@yahoo.com>]

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 :-)

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.

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>

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

Re: Obscuring passwords in new ways

[Donald Woods <dw...@apache.org>]

Vamsavardhana Reddy wrote:
> 
> 
> On 9/15/07, *David Jencks* <david_jencks@yahoo.com 
> <ma...@yahoo.com>> wrote:
> 
> 
>     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* < david_jencks@yahoo.com
>>     <ma...@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"?
> 
>     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. 
> 
> 
> Which user program are we referring to?
>  
> 
>>         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 :-)
> 
> 
> Sometime ago I had some code locally (not as part of the server code, 
> but a simple program that searches for config.ser's in the repository 
> and encrypts)  to encrypt all config.ser's based on a password and write 
> the "salt" used to a file in the server's directory.  When server 
> starts, it looks for this "salt" file and asks for the password so that 
> config.ser's can be decrypted and loaded.  We may use something similar 
> without a startup password  In this case, a loss of password would mean 
> a totally unusable server :(.

That sounds like a great option to add, for those users who really want to 
secure their server.  Can you open a JIRA so we don't forget to revisit this 
thought?


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

Agree and this could be another enhancement, that we allow users to provide 
XML with whole or attribute encryption (like Apache WSS4J for WS-Security) and 
   a tool to encrypt the plans....


> 
> Even if there is a deployment plan in the configuration's dir, there is 
> no guarantee that it is the one used for deployment as it may have been 
> deployed using an external deployment plan.
> 
>>     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?
> 
> 
> You are fine.
> 
>     thanks!
>     david jencks
> 
> 

Re: Obscuring passwords in new ways

[Vamsavardhana Reddy <c1...@gmail.com>]

On 9/15/07, David Jencks <da...@yahoo.com> wrote:
>
>
> 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 <da...@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"?
>
>
> 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.
>

Which user program are we referring to?


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 :-)
>

Sometime ago I had some code locally (not as part of the server code, but a
simple program that searches for config.ser's in the repository and
encrypts)  to encrypt all config.ser's based on a password and write the
"salt" used to a file in the server's directory.  When server starts, it
looks for this "salt" file and asks for the password so that config.ser's
can be decrypted and loaded.  We may use something similar without a startup
password  In this case, a loss of password would mean a totally unusable
server :(.

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

Even if there is a deployment plan in the configuration's dir, there is no
guarantee that it is the one used for deployment as it may have been
deployed using an external deployment plan.

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

You are fine.

thanks!
> david jencks
>
>

Re: Obscuring passwords in new ways

[David Jencks <da...@yahoo.com>]

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 <da...@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"?

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

Re: Obscuring passwords in new ways

[Vamsavardhana Reddy <c1...@gmail.com>]

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

Re: Obscuring passwords in new ways

[Aaron Mulder <am...@alumni.princeton.edu>]

Sounds nice!

Aaron

On 9/14/07, David Jencks <da...@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 :-)
>
> 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.
>
> 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>
>
> 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
>
>
>