db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bernt M. Johnsen" <Bernt.John...@Sun.COM>
Subject Re: DRDA Password Encryption (SECMEC_EUSRIDPWD and SECMEC_USRENCPWD)
Date Sat, 18 Jun 2005 16:25:35 GMT
>>>>>>>>>>>> Kathey Marsden wrote (2005-06-17 19:37:45):
> Bernt M. Johnsen wrote:
> 
> >Have I missed something or is it impossible to get password
> >encryption.
> >  
> >
> Hi Bernt,
> 
> This issue is logged as DERBY-65.  I am sorry to say this  is an area
> with which I am not too familiar but the protocol specification talks
> about  Security in  Chapter 10 of  Volume 1.   I think there is hope.
> 
> See
> http://www.opengroup.org/onlinepubs/9699959699/toc.pdf 

I have checked out the spec. And as far as I can see, there is no way
passwords may be encryptet as long as SunJCE (and possible IBMJCE)
don't support DRDA password encryption with the 32 (256 bit)
Diffie-Hellman agreed public values (specfied in Volume 3, p 644
http://www.opengroup.org/onlinepubs/9699959499/toc.pdf) for key
generation.

One way around is to be to specify a larger non-standard value
e.g. 1024 bits.

Another way around is to look more closely into user authentication
for client-server. Today the Derby client just sends username/password
to the server and then the user is authenticated the same way as with
the embedded Derby. The current authentication scheme is very flexible
(simple password, LDAP, user-defined etc). DRDA defines both Kerberos
and password hashing schemes, so we aren't necessarily stuck to
password encryption with authentication on the server. 

-- 
Bernt Marius Johnsen, Database Technology Group, 
Sun Microsystems, Trondheim, Norway

Mime
View raw message