From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | José Luis Tallón <jltallon(at)adv-solutions(dot)net> |
Cc: | Claudio Freire <klaussfreire(at)gmail(dot)com>, Magnus Hagander <magnus(at)hagander(dot)net>, Robert Haas <robertmhaas(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: reducing our reliance on MD5 |
Date: | 2015-02-11 15:40:48 |
Message-ID: | 5165.1423669248@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
=?UTF-8?B?Sm9zw6kgTHVpcyBUYWxsw7Nu?= <jltallon(at)adv-solutions(dot)net> writes:
> In any case, just storing the "password BLOB"(text or base64 encoded)
> along with a mechanism identifier would go a long way towards making
> this part pluggable... just like we do with LDAP/RADIUS/Kerberos/PAM today.
That's exactly the direction we must NOT go.
Upgrading the security of stored passwords in pg_authid is at least as
important as upgrading the wire protocol security; very possibly more so.
Any solution that requires cleartext passwords to be kept by the server
is simply not going to be accepted.
Because of this constraint, I really suspect that we have zero chance of
achieving pluggability or farming out the problem to some third party
library.
Or in short: we've done that before, with LDAP/RADIUS/Kerberos/PAM,
and none of those solutions have proven very satisfactory; they certainly
have not replaced passwords to any measurable degree. Expecting the next
external solution to do so is the definition of insanity.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | José Luis Tallón | 2015-02-11 15:54:10 | Re: reducing our reliance on MD5 |
Previous Message | Claudio Freire | 2015-02-11 15:34:21 | Re: reducing our reliance on MD5 |