Re: So we're in agreement....

Philip Warner <pjw@rhyme.com.au> writes:
> To solve (2) it seems to me that a slightly more complex interaction must
> be undertaken using a public key algorithm:

>  - Client sends [username] to server
>  - Server sends [public key] to client
>  - Client sends [enc(public key, password)] to server. 
>  - server uses dec(secret key,enc) and computes MD5 hash of password,
> comparing it to pg_shadow.

Hmm.  The main problem with this is that once we get into having actual
encryption/decryption code in Postgres, we are going to run afoul of US
export regulations and other headaches.  MD5 doesn't pose that problem
because it's only a hashing algorithm not an encryptor.  I see your
point though, that requiring the client to send something one step
upstream from what's stored in pg_shadow would make it harder to do
anything useful by stealing pg_shadow.  Can we get the same result with
just MD5 operations?

One possibility that comes to mind is that we store MD5(MD5(password))
in pg_shadow, and expect the client to transmit MD5(password).
Of course that needs a cloaking scheme if you want to protect against
password sniffing, but offhand it seems that the same scheme Ben Adida
proposed should still work...

> Additionally, it may be good to allow the entire client/server comms to be
> done as an encrypted interaction, since a man-in-the-middle may not be able
> to read the password, but they will be able to read the data...

We have SSL capability already.  I don't feel an urge to reinvent SSL.
        regards, tom lane