On Sat, Aug 8, 2015 at 3:45 AM, Heikki Linnakangas <hlinn...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers