[ http://issues.apache.org/jira/browse/DERBY-962?page=all ]
Sunitha Kambhampati updated DERBY-962:
--------------------------------------
Attachment: Derby962_forreview.diff.txt
Derby962_forreview.stat.txt
This patch 'Derby962.forreview.diff.txt' is a patch for review. This patch
needs derby 1080 for it to work. Also there is one testfile which is common
between the derby-1080 and this patch and hence it is likely this patch may not
apply cleanly once derby1080 gets reviewed and committed. I generated the diff
keeping the changes of derby1080 for the test file (derbynet/testSecMec.java).
This patch 'Derby962.forreview.diff.txt' improves the upgrade security
mechanism logic to do the following.
1. If securityMechanism is explicitly specified in the connection request then
client will not override it.
2. Dynamically figure out if the jvm in which the client is loaded, supports
encrypted userid and
password security (EUSRIDPWD) or not and use this information to upgrade to a
more secure default
security mechanism.
3. Thus if user has not specified the security mechanism, in that case the
client will try to see if
it can upgrade the security mechanism and use the new upgraded security
mechanism for connection to the server.
Logic in ClientBaseDataSource#getUpgradedSecurityMechanism()
+ * This method has logic to upgrade security mechanism to a better (more
secure) one
+ * if it is possible. Currently derby server only has support for
USRIDPWD,USRIDONL,
+ * EUSRIDPWD and this method only considers these possibilities.
+ * USRIDPWD, EUSRIDPWD require a password, USRIDONL is the only security
mechanism
+ * which does not require password.
+ * 1. if password is not available, then security mechanism possible is
USRIDONL
+ * 2. if password is available, if client supports EUSRIDPWD, then
EUSRIDPWD is
+ * returned
+ * 3. if password is available, if client does not support EUSRIDPWD, then
USRIDPWD
+ * is returned.
Testing:
-- Added tests with possible permutations for user, password and security
mechanism on a connection request.
see derbynet/testSecMec.java#testAllCombinationsOfUserPasswordSecMecInput()
I have attached a table to this jira entry (962_table.txt) that gives
information about what security mechanism the client sends to the server on
different possible inputs.
-- Ran derbyall on linux/ibm142 ok with known failures.
-- Ran derbynet/testSecMec.java on windows with sane classes for both
derbynet(JCC2.4 and JCC2.6)
/derbynetclientmats with ibm131/ibm15/jdk131/jdk15/ibm142/jdk142.
Please note: this patch depends and requires fix for derby1080. Most likely
when 1080 gets reviewed and committed, this patch may not cleanly apply.
Can someone please review this change. Thanks.
> 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
