On Tue, Nov 15, 2016 at 07:52:06AM +0900, Michael Paquier wrote: > On Sat, Nov 5, 2016 at 9:36 PM, Michael Paquier <michael.paqu...@gmail.com> > wrote: > > On Sat, Nov 5, 2016 at 12:58 AM, Peter Eisentraut > > <peter.eisentr...@2ndquadrant.com> wrote: > > pg_hba.conf uses "scram" as keyword, but scram refers to a family of > > authentication methods. There is as well SCRAM-SHA-1, SCRAM-SHA-256 > > (what this patch does). Hence wouldn't it make sense to use > > scram_sha256 in pg_hba.conf instead? If for example in the future > > there is a SHA-512 version of SCRAM we could switch easily to that and > > define scram_sha512. > > OK, I have added more docs regarding the use of scram in pg_hba.conf, > particularly in client-auth.sgml to describe what scram is better than > md5 in terms of protection, and also completed the data of pg_hba.conf > about the new keyword used in it.
The latest versions document this precisely, but I agree with Peter's concern about plain "scram". Suppose it's 2025 and PostgreSQL support SASL mechanisms OAUTHBEARER, SCRAM-SHA-256, SCRAM-SHA-256-PLUS, and SCRAM-SHA3-512. What should the pg_hba.conf options look like at that time? I don't think having a single "scram" option fits in such a world. I see two strategies that fit: 1. Single "sasl" option, with a GUC, similar to ssl_ciphers, controlling the mechanisms to offer. 2. Separate options "scram_sha_256", "scram_sha3_512", "oauthbearer", etc. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
