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 #:)
Kathey
