db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kathey Marsden (JIRA)" <derby-...@db.apache.org>
Subject [jira] Commented: (DERBY-962) Upgrade default security mechanism in client to use encrypted userid password if client can support it.
Date Fri, 10 Mar 2006 21:53:46 GMT
    [ http://issues.apache.org/jira/browse/DERBY-962?page=comments#action_12369929 ] 

Kathey Marsden commented on DERBY-962:

Thanks Sunitha for working on this issue and working toward a secure network client and server.
I looked at your table and the code patch diff, but did not apply it because I had trouble
doing so, so this review is probably pretty rough. 

Your table is very useful and I think it should be incorporated into the test  or code comments.
 Perhaps the following could be clarified. 

-  In your explanation of columns in the table you refer to the columns as a), b) etc.  It
would be good to put those letters in the column headers.

- In your explanations section also list how the numeric values map to the security mechanisms
for reference.
  It is further down on the page, but I noticed that after loooking them up.

- The first section of the table is for the case where  no security mechanism is specified.
 It would be good to call that  out in a header as  you do before the other sections of the

In the code, I am unsure about the impact of adding this code to the static initializer block.
   I know you had asked about it earlier and I wish I had insight to the implications but
just don't.   Hopefully someone else does.

+    {
+        try
+        {
+            // The EncryptionManager class will instantiate objects of the required 
+            // security algorithms that are needed for EUSRIDPWD
+            // An exception will be thrown if support is not available
+            // in the JCE implementation in the JVM in which the client
+            // is loaded.
+            new org.apache.derby.client.am.EncryptionManager(null);
+            SUPPORTS_EUSRIDPWD = true;
+        }catch(Exception e)
+        {
+            // if an exception is thrown, ignore exception.
+            // set SUPPORTS_EUSRIDPWD to false indicating that the client 
+            // does not support EUSRIDPWD security mechanism
+            SUPPORTS_EUSRIDPWD = false;
+        }
+    }

Maybe it would be good to change SECMEC_HAS_NOT_EXPLICITLY_SET   to something like SECMEC_DEFAULT
for clarification.  Something about the negatives in variable names always confuses me.


> Upgrade default security mechanism in client to use encrypted userid password if client
can support it.
> -------------------------------------------------------------------------------------------------------
>          Key: DERBY-962
>          URL: http://issues.apache.org/jira/browse/DERBY-962
>      Project: Derby
>         Type: Improvement
>   Components: Network Client
>     Reporter: Sunitha Kambhampati
>     Assignee: Sunitha Kambhampati
>      Fix For:
>  Attachments: 962_table.txt, Derby962_forreview.diff.txt, Derby962_forreview.stat.txt
> Currently in the client, if userid and password are set in the connection url, the default
security mechanism is upgraded to USRIDPWD (which is clear text userid and password).  This
seems to be a security hole here. 
> Current client  driver supports encrypted userid/password (EUSRIDPWD) via the use of
DH key-agreement protocol - however current Open Group DRDA specifications imposes small prime
and base generator values (256 bits) that prevents other JCE's  (apt from ibm jce) to be used
as java cryptography providers.  
> Some thoughts:
> -- client can make a check to see if it the jvm it is running in supports the encryption
necessary for EUSRIDPWD. If it supports, then the client can upgrade to EUSRIDPWD. 
> -- if the jvm the client is running is , doesnt support encryption requirements for EUSRIDPWD,
then the security mechanism will be set to USRIDPWD.
> -- DERBY-528 will add support for strong userid and password which is another option
to send encrypted passwords across the wire. When this gets added, maybe this can be considered
as one of the upgrade options after EUSRIDPWD. 

This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
For more information on JIRA, see:

View raw message