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