Re: [HACKERS] scram and \password
От | Heikki Linnakangas |
---|---|
Тема | Re: [HACKERS] scram and \password |
Дата | |
Msg-id | 56f6c214-f433-3758-7753-3081963b45a9@iki.fi обсуждение исходный текст |
Ответ на | Re: [HACKERS] scram and \password (Michael Paquier <michael.paquier@gmail.com>) |
Ответы |
Re: [HACKERS] scram and \password
|
Список | pgsql-hackers |
On 04/10/2017 08:42 AM, Michael Paquier wrote: > As there have been some conflicts because of the commit of SASLprep, > here is a rebased set of patches. A couple of things worth noting: > - SASLprep does an allocation of the prepared password string. It is > definitely better to do all the ground work in pg_saslprep but this > costs a free() call with a #ifdef FRONTEND at the end of > scram_build_verifier(). > - Patch 0005 does that: > + /* > + * Hash password using SCRAM-SHA-256 when connecting to servers > + * newer than Postgres 10, and hash with MD5 otherwise. > + */ > + if (pset.sversion < 100000) > + encrypted_password = PQencryptPassword(pw1, user, "md5"); > + else > + encrypted_password = PQencryptPassword(pw1, user, "scram"); > Actually I am thinking that guessing the hashing function according to > the value of password_encryption would make the most sense. Thoughts? Thanks! I've been busy on the other thread on future-proofing the protocol with negotiating the SASL mechanism, I'll come back to this once we get that settled. By the end of the week, I presume. Not sure about the password-encryption thing, there are good arguments for either behavior.. - Heikki
В списке pgsql-hackers по дате отправления: