db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kathey Marsden <kmarsdende...@sbcglobal.net>
Subject Re: DRDA Password Encryption (SECMEC_EUSRIDPWD and SECMEC_USRENCPWD)
Date Sat, 18 Jun 2005 22:48:05 GMT
Bernt M. Johnsen wrote:

>Another way around is to look more closely into user authentication
>for client-server.
I think that is a good idea to look at the whole client-server
authentication picture, and also look at access for administration and
the default access options.  In addition to the limited JVM options for
password encryption there are other issues.

    * Network Server starts up with only localhost  access by default,
because to enable remote access,  you should  enable user authentication
and run under Java 2 Security manager, steps which I am concerned are
often committed.
    * We never allow administration commands such as runtimeinfo, and
shutdown to be performed remotely because there is no authentication for
this type of access. 
     * Any database name and connection attributes can passed  to
network server, allowing attributes such as shutdown of the database,
creation of  a new database, etc.
    * There is no data stream encryption.
     * Derby does not have GRANT/REVOKE.  So users are either in or out
pretty much.
So, I tend to think that  more is needed than just more bits for
encryption or Kerberos.    Again I haven't looked into it but wonder
if   SSL support can solve a lot of these problems and then we don't
have to worry too much about the limitations of the underlying 
client-server protocol.   So yes lets  *look more closely into user
authentication  and security in general for client-server*   And as an
extra credit item ...

I  would like to see network server start up, by default,  secure and
remotely accessible, but  I don't think there is any way with Java to
verify users with the underlying operating system, but that would be
really great too #:)


View raw message