On Wed, Mar 15, 2017 at 6:14 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Jeff Janes <jeff.ja...@gmail.com> writes: >> On Tue, Mar 14, 2017 at 8:40 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: >>> Why exactly would anyone want "md5 only"? I should think that "scram >>> only" is a sensible pg_hba setting, if the DBA feels that md5 is too >>> insecure, but I do not see the point of "md5 only" in 2017. I think >>> we should just start interpreting that as "md5 or better". > >> Without md5-only, a user who uses \password to change their password from a >> newer client would lock themselves out of connecting again from older >> clients. As a conscious decision (either of the DBA or the user) that >> would be OK, but to have it happen by default would be unfortunate. > > That's a point, but what it implies is that \password needs some input > from the user about whether to generate a SCRAM or MD5-hashed password. > It would be a fatal error to try to drive that off the auth method > that had been used for the current connection, even if \password had a > way to find that out. By definition, your concern is about clients > other than the current one, which might well be coming in from other > addresses and getting challenges based on other pg_hba entries. So > you can't say that "I came in on a SCRAM connection" is sufficient > reason to generate a SCRAM password. > > In short, I don't think that argument refutes my position that "md5" > in pg_hba.conf should be understood as allowing SCRAM passwords too.
I have been hacking my way through this thing, and making scram_build_verifier is requiring a bit more refactoring than I thought first: - stored and server keys are hex-encoded using a backend-only routine. I think that those should be instead base64-encoded using what has already been moved in src/common/. - Callers of scram_build_verifier() need to allocate by themselves the verifier, and feed it to the function similarly to MD5. - Frontend-side random generation function is needed, so I have moved pg_frontend_random() into its own file in src/common/. Attached are four patches: - 0001: Switch server and stored keys to be base64-encoded. - 0002: Move pg_frontend_random() to src/common/ - 0003: Move scram_build_verifier() to src/common/ - 0004: Extend PQencryptPassword with a method argument, able to handle SCRAM, MD5 and cleartext. I have not yet done the psql portion with \password -method (too tired), and in 0004 all the calls of PQencryptPassword use "scram" for the purpose of the demonstration. Even if PQencryptPassword is not extended at the end, patches 0001~0003 are necessary anyway. -- Michael
0001-Use-base64-based-encoding-for-stored-and-server-keys.patch
Description: Binary data
0002-Refactor-frontend-side-random-number-generation.patch
Description: Binary data
0003-Move-routine-to-build-SCRAM-verifier-into-src-common.patch
Description: Binary data
0004-Extend-PQencryptPassword-with-a-hashing-method.patch
Description: Binary data
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers