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.
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).
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.
- Heikki -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
