I wrote:
> The main potential hazard I see is portability. Is crypt(3) available
> on *all* the platforms Postgres runs on?
Waitasec, what am I saying? We already *do* have crypt password
support, at least on those platforms where crypt(3) is available.
As near as I can tell, the crypt option transmits an encrypted password
across the wire (good), but the comparison at the server end is done by
taking the cleartext password stored in pg_shadow, crypt()ing it on
the fly, and comparing that to what was sent by the client.
This does have the advantage that the same pg_shadow entry will support
both cleartext-password and crypted-password connections, but we could
get that another way. Assuming that the server has crypt(), the
password could be stored always encrypted instead of always not.
Cleartext-password connections would be handled just by crypting the
received password before comparing. (Before you ask, no I don't think
we should remove the option of cleartext-password connections. What of
clients running on platforms with neither crypt() nor anything better
like Kerberos? Should they be forced to drop down to no security at
all? I think not.)
This'd take some rejiggering in (at least) CREATE USER and ALTER USER,
but it seems doable. I withdraw the complaint about portability...
regards, tom lane
