[
http://issues.apache.org/jira/browse/DERBY-962?page=comments#action_12366737 ]
Sunitha Kambhampati commented on DERBY-962:
-------------------------------------------
I just started looking at this issue on how to know if the jvm in which the
client is running can support encrypted userid and password mechanism or not;
to decide if we can upgrade the default security mechanism.
I wanted to share some thoughts I have, so I could get early feedback from the
list.
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.
-- org.apache.derby.client.am.EncryptionManager (EM) constructor is responsible
for instantiating the appropriate Provider and the KeyPairGenerator. The Sun
JCE throws java.security.InvalidAlgorithmParameterException exception when
trying to use the 256bits prime.
I think we can conclude if the EM throws an exception, then the JCE doesnt
support the required algorithms.
=> An exception from this constructor indicates that it is not possible to use
encrypted userid/password.
The next step seems to me to decide where to put the call to new
EncryptionManager(EM)
#A.Put in static initializer block in ClientBaseDataSource and store the result
in a static variable. The ClientBaseDataSource seems to be place where all the
url attribute values' gets and sets methods are present. Also the upgrade logic
for the security mechanism is in this class.
something like:
static boolean SUPPORTS_EUSRIDPWD = false;
static
{
try
{
new org.apache.derby.client.am.EncryptionManager(null);
SUPPORTS_EUSRIDPWD = true;
}catch(Exception e)
{
//ignore
}
}
---------------
#B. Another place this check could go was in the ClientDriver itself since this
will be loaded in the JVM. In the static initializer of ClientDriver, new of
EM can be done to check if it will go through OK. If so, a static 'protected'
variable in ClientDriver can be used to store the state that the driver
supports the algorithms required for encrypted userid/password.
1. Are there any issues with adding code to the static initializer block of the
Client Driver. I see the following comment in ClientDriver which sounds a
little scary to me.
static {
// This may possibly hit the race-condition bug of java 1.1.
// The Configuration static clause should execute before the following
line does.
if (Configuration.exceptionsOnLoadResources != null) {
......
}
I can see that the Configuration static initializer needs to run before the
access to the static variable Configuration.exceptionsOnLoadResources.
I'm curious and would like to look at it sometime. If someone could point me to
some reference of this bug, I'd be grateful. I googled but didnt find any
related to the static intializer blocks.
--------------
#C Explicitly check the jvm and decide. Not a good way for e.g. if SunJCE
supports the DH with 256 bits prime some day, we would have to remember to
remove this check that disables encrypted userid/password for this particular
JVM.
I like #A because it seems clean. What do others think ?
Comments/Thoughts.
Thanks much,
Sunitha.
> 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
> Fix For: 10.2.0.0
>
> 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
