Re: You're on SecurityFocus.com for the cleartext passwords.

Would public/private key pair authentication (like GPG) or SSL-like solutions
work? If the backend could use SSL, it would have the ability to protect
passwords and all data too from being seen on the network.  Somekind of SSL
ability would solve all security problems.  Can't OpenSSL be used on top of the
client/backend connection?  This way, the backend/database could just store
hashed passwords anyway it wants and the client only needs to support the
SSL-like layer in the connection.  I guess this would mean adding SSL into the
libraries (libpq etc) for the functions that make the backend connection.  It
would be nice if after user authentication, that the protocol could optionally
renegotiate back to an unencrypted connection for speed.  A security option
could be added to databases that allows the DBA to specify whether or not
access to the database requires a secure connection to protect the sensitive
info.

I'm probably not understanding everything here, but if system crypt() is used,
it looks like you have to go with the least common denominator algorithm
that is on all platforms, which might be the old 2-byte salt DES.  But if you
embed all this in the libpq etc, then you use whatever you want.

Also, isn't the salt the first x bytes of the hashed string, x depending on
which algorithm used?  Wouldn't things work like this:

1. Server sends the first 2 (or x bytes) of the hashed password (e.g., the salt
used to make the hashed password.
2. The client hashes the password with the salt and sends it back to the server.
3. The server compares what the client sent with the hash it has stored.  If
they match the user is let in.  I didn't think there was any need for this
random salt and double hashing thats been discussed.

If you have to implement something into the backend and the client libraries,
why not go for an SSL type solution?

(people might say, it sounds fine, why don't YOU do it :)
Robert Easter