> I agree with Gene. Following this discussion, I sense a reluctance to
> implement stronger password schemes because of the extra development
> hassles (compatibility, crypto prohibitions, maintenance).
>
> 1) Divide and conquer: the developers are concerned about both "over the
> wire" and server passwords. I suggest you focus on the server side and
> leave the over the wire security to the DB admin/sys.admin as an
> installation issue. If they choose to use SSL, SSH, IPsec or a home-grown
> authentication handshake, that's of no concern to pgsql. Just think of it
> as a telnet session into the server.
>
> 2) On the server side, use the native crypt(3) by default (or the NT
> equivalent) and store the password hash. The strength of the crypt will
> vary depending on the installation, but that's really up to the choice of
> OS and installation. If someone wants to patch for PAM, Kerberos or
> whatever, that's fine too, as long as you can always revert back to the
> plain old crypt(3).
>
I disagree. Over the wire seems more important than protecting the
passwords from the eyes of the database administrator, which in _most_
cases is the system owner anyway.
-- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610)
853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill,
Pennsylvania19026