On Sun, Mar 12, 2017 at 5:35 AM, Joe Conway <m...@joeconway.com> wrote: > On 03/10/2017 02:43 PM, Michael Paquier wrote: >> Instead of changing the default, I think that we should take this >> occasion to rename PQencryptPassword to something like >> PQhashPassword(), and extend it with a method argument to support both >> md5 and scram. PQencryptPassword could also be marked as deprecated, >> or let as-is for some time. For \password, we could have another >> meta-command but that sounds grotty, or just extend \password with a >> --method argument. Switching the default could happen in another >> release. >> >> A patch among those lines would be a simple, do people feel that this >> should be part of PG 10? > > Seems like it should work in an analogous way to CREATE/ALTER ROLE. > According to the docs: > > 8<---- > ENCRYPTED > UNENCRYPTED > > These key words control whether the password is stored encrypted in > the system catalogs. (If neither is specified, the default behavior is > determined by the configuration parameter password_encryption.) If the > presented password string is already in MD5-encrypted or SCRAM-encrypted > format, then it is stored encrypted as-is, regardless of whether > ENCRYPTED or UNENCRYPTED is specified (since the system cannot decrypt > the specified encrypted password string). This allows reloading of > encrypted passwords during dump/restore. > 8<---- > > So if the password is not already set, \password uses > password_encryption to determine which format to use, and if the > password is already set, then the current method is assumed.
Yeah, the problem here being that this routine does not need a live connection to work, and we surely don't want to make that mandatory, that's why I am suggesting something like the above. Another approach would be to switch to SCRAM once password_encryption does this switch as well... There is no perfect scenario here. -- Michael -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
