Re: WIP: SCRAM authentication

On Sat, Aug 8, 2015 at 3:45 AM, Heikki Linnakangas <hlinnaka@iki.fi> wrote:
> On 08/07/2015 09:26 PM, Robert Haas wrote:
>>
>> Maybe I'm chiming in too late here but I am sorta unimpressed by this.
>> If the user's password is stored both MD5-hashed and hashed some other
>> way in the system catalogs, that's less secure than storing it in the
>> least secure of those ways.  And I'm afraid that if we introduce this
>> new mechanism, we won't really gain any security, because everybody
>> will just pg_dump or pg_upgrade and the old passwords will stick
>> around in the system forever.  In fact we might lose security if
>> somebody changes one password verifier but doesn't realize that the
>> other one is still floating around, memorializing the old password,
>> and still available to be used for login.
>
>
> Yeah, that's certainly a risk. You wouldn't want to keep around verifiers
> for authentication methods you don't use.

Yep, I cannot refute that. And there is actually the same problem with
the first version of the patch proposed on this thread if that's what
you are referring at below.

>> I think we should look for a solution that either (a) allows SCRAM
>> authentication without requiring any changes to the contents of
>> pg_authid, like what Heikki proposed before; or (b) forces a hard
>> break, where at each password change you can decide if you want the
>> old or new format (probably based on the current value of some
>> compatibility GUC).

FWIW, the patch resets all the existing entries should any
CREATE/ALTER ROLE involving a password should be run, even if
pg_auth_verifiers has entries for method not specified with PASSWORD
VERIFIERS.

> Yeah, something to force a hard break when you want it would be really good.
> Perhaps a command you can run to remove all MD5 hashes, or at least find all
> the roles that have them. And a GUC to disallow creating new ones.

This filtering machinery definitely looks like a GUC to me, something
like password_forbidden_encryption that PASSWORD VERIFIERS looks at
and discards the methods listed in there. This definitely needs to be
separated from password_encryption.
-- 
Michael