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 Sun, 16 Sep 2007 21:56:32 GMT


David Jencks commented on GERONIMO-2925:

Re Jarek's comments:

- looking for initial '{' is only to decide whether to try to decode first.  If it isn't followed
by a registered encryption name the decryption will return the original string.  So you can
encrypt anything that doesn't start with a registered encription name.

- trying to decrypt something that doesn't start with a registered encryption name will return
the original input.

- currently the response to exceptions is to return null.... I don't think this is very appropriate
but I'm not sure what is better.  Suggestions?

- I think the proposed behavior of making EncryptionManager.encrypt and decrypt idempotent
is a good idea as it significantly simplifies all the callers.

Some documentation of what is intended would definitely be a good idea.  I'll add it if and
before I commit.

> 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-M5
>            Reporter: Michael Malgeri
>            Assignee: David Jencks
>            Priority: Critical
>         Attachments: GERONIMO-2925.patch
> 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