geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Jencks (JIRA)" <>
Subject [jira] Commented: (GERONIMO-2925) Key used for encryption same for all server instances
Date Fri, 02 Mar 2007 22:46:50 GMT


David Jencks commented on GERONIMO-2925:

Did you intend to file this in an IBM issue tracker?  If not, why does it refer to WASCE?

Who is "we"?

Exactly what attack is "we" trying to protect against?  Specifically which files is "we" talking
about?  The current solution makes it so that someone casually looking at config.xml can't
read off the passwords that might be overridden there. I think this is an appropriate level
of security.  Any solution that involves the server reading a key from some file to use for
decryption has the same level of security as the current one unless "we" wants to be able
to publish whatever files they are talking about without danger.  Anyone who can get to config.xml,
say, can also find the file the key is stored in.

If "we" is concerned about config.xml, and wants to be able to publish it without danger,
perhaps a more appropriate solution would be to use the property substitution suggested in
GERONIMO-2735 and keep the properties file secured.  If that's not appropriate perhaps the
vault proprosed in would be something
to think about.

I don't have a problem with making the encryption more pluggable, but I'd like to understand
the benefit first.  There might be other simpler more secure solutions as well, such as supplying
the encryption key as a system property on the command line. (at least if you turn off bash_history)

> Key used for encryption same for all server instances
> -----------------------------------------------------
>                 Key: GERONIMO-2925
>                 URL:
>             Project: Geronimo
>          Issue Type: Bug
>      Security Level: public(Regular issues) 
>          Components: security
>    Affects Versions: 1.1.1, 1.1.2, 1.1.x, 1.2, 2.0
>            Reporter: Michael Malgeri
>            Priority: Critical
> We understand that WASCE use AES to encrypt the password.  You do 
> javax.crypto.Cipher.getInstance("AES") and init() with a hard-coded key.
> This key is same for all the WASCE server instances.  Anyone getting access to a downloaded
version of the software can have the algorithm and decrypt the password.  So we need your
urgent help on the following:
> 1. provide a solution with key management that we can control
> 2. provide a pluggable encryption solution so that we can use our internal algorithms
and key management
> At least,
> 3. the key should be dynamically generated in each of the installations that would reduce
the ability to decrypt to someone who has access to the server.

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message