[jira] Commented: (DERBY-962) Upgrade default security mechanism in client to use encrypted userid password if client can support it.

["Kathey Marsden (JIRA)" <de...@db.apache.org>]

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


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.

 static
+    {
+        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.

Kathey




> 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: 10.2.0.0
>  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:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

Re: [jira] Commented: (DERBY-962) Upgrade default security mechanism in client to use encrypted userid password if client can support it.

[Sunitha Kambhampati <ks...@gmail.com>]

Thanks Kathey for looking at this patch.

Kathey Marsden (JIRA) wrote:

>Your table is very useful and I think it should be incorporated into the test  or code comments.  Perhaps the following could be clarified. 
>  
>
I'll add the table into the test comments.  I am actually working on 
putting a page on Wiki for the security mechanism related information 
that I have been working on.

>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.
>
>  
>
I think the static init block in the ClientBaseDataSource is ok, but I 
was worried about implications of putting it in the ClientDriver static 
init block.

>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.
>  
>
This variable is used to indicate that the security mechanism has not 
been set on datasource or connection request.  I can change it to 
SECMEC_DEFAULT if that is preferred. 

Its just that SECMEC_DEFAULT seems to suggest that it is the default 
security mechanism which it isnt.  The default security mechanism for 
the client is USRIDONL (0x04)

Thanks again Kathey for reviewing this patch.
Sunitha.