[
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
