On 02/11/2015 04:40 PM, Tom Lane wrote:
=?UTF-8?B?Sm9zw6kgTHVpcyBUYWxsw7Nu?= <jltal...@adv-solutions.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.
I definitively haven't explained myself properly.
I *never* suggested storing plaintext in pg_authid, but using plaintext
authentication (which can always be matched against an on-disk hash,
whatever the type) as a fallback to allow for seamless upgrades of security.
(once you are authenticated by using the old credentials, the
server can transparently store the new hash)
When I referred to a "text or base64 encoded" I never implied on-disk
plaintext (unless the user specifically requires that, which they might).
To avoid ambiguities, my proposal closely mimicks Dovecot's
implementation of password schemes and credential upgrades
http://wiki2.dovecot.org/Authentication/PasswordSchemes
Thanks,
J.L.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
