From: | José Luis Tallón <jltallon(at)adv-solutions(dot)net> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
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:54:10 |
Message-ID: | 54DB7B22.4040704@adv-solutions.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 02/11/2015 04:40 PM, Tom Lane wrote:
> =?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.
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.
From | Date | Subject | |
---|---|---|---|
Next Message | Joshua D. Drake | 2015-02-11 16:34:18 | Re: reducing our reliance on MD5 |
Previous Message | Tom Lane | 2015-02-11 15:40:48 | Re: reducing our reliance on MD5 |