[jira] Commented: (GERONIMO-2925) Key used for encryption same for all server instances

["David Jencks (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/GERONIMO-2925?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12477537 ] 

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 https://issues.apache.org/jira/browse/GERONIMO-1486 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: https://issues.apache.org/jira/browse/GERONIMO-2925
>             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.