* Tom Lane (tgl@sss.pgh.pa.us) wrote:
> Stephen Frost <sfrost@snowman.net> writes:
> > I'd also like to point out that this is *only* an issue for the 'md5'
> > authentication mechanism in pg_hba.conf, which I think should be=20
> > discouraged in favor of 'password' and SSL/IPSEC.
>
> This is still utter nonsense. How can md5 be less secure than storing
> your password in the clear?
I think you're mixing the issues. 'password' in pg_hba.conf does not
automatically imply 'without encrypted password'/plaintext in pg_shadow.
There are two seperate uses of md5 here and they counter each other.
If you use 'md5' in pg_hba.conf then using 'with encrypted password'/md5
in pg_shadow is pointless because the authentication token is the hash
which is stored in cleartext in pg_shadow. If you don't use 'with
encrypted password' in pg_shadow then you can't use 'md5' in pg_hba.conf
in the currently implementation- but there's no particular reason for
that to be the case, and that could be fixed.
If you use 'with encrypted password' and a random salt then you can't
use 'md5' in pg_hba.conf w/o sending the salt, which defeats the point
of it being random. It's an interesting interaction.
> Whether you want the extra security of IPSEC is an orthogonal discussion
> really; if your connection goes over an insecure network then you most
> likely need it in order to hide your data, never mind your password.
This statement actually argues to my point that the 'md5' *transport*
usage, using 'md5' in pg_hba.conf, should be discouraged, since it
doesn't protect the data. I do feel that we should use md5 for
pg_shadow. In using md5 in pg_shadow I feel we should use a random salt
that is not given out and is stored in pg_shadow. This is not a problem
if the 'password' *tranport* mechanism in pg_hba.conf is used since the
password is sent to the server by the client in the clear and is not
hashed at all- that is done on the server and must always be done by the
server for that mechanism.
Thanks,
Stephen
