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
