Greetings,
* Peter Eisentraut (peter.eisentraut@2ndquadrant.com) wrote:
> On 2019-08-12 18:02, Jeff Davis wrote:
> > https://postgr.es/m/daf0017a1a5c2caabf88a4e00f66b4fcbdfeccad.camel%40j-davis.com
> >
> > The weakness of proposal #1 is that it's not very "future-proof" and we
> > would likely need to change something about it later when we support
> > new methods. That wouldn't break clients, but it would be annoying to
> > need to support some old syntax and some new syntax for the connection
> > parameters.
> >
> > Proposal #3 does not have this weakness. When we add sha-512, we could
> > also add a parameter to specify that the client requires a certain hash
> > algorithm for SCRAM.
> >
> > Do you favor that existing proposal #3, or are you proposing a fourth
> > option?
>
> In this context, I would prefer #2, but I would expand that to cover all
> authentication methods, not only password methods.
I'm not really thrilled with approach #2 because it means the user
will have to know which of the PG authentication methods involve, eg,
sending the password in the clear to the server, and which don't, if
what they're really looking for is "don't send my password in the clear
to the server" which seems like a really useful and sensible thing to
ask for.
It also ends up not being very future-proof either, since a user who is
fine with scram-sha-256-plus will probably also be ok with
scram-sha-512-plus, should we ever implement it.
Not to mention that, at least at the moment, we don't let users pick
authentication methods with that kind of specificity on the server side
(how do you require channel binding..?), so the set of "authentication
methods" on the client side and those on the server side end up being
different sets, which strikes me as awfully confusing...
Or did I misunderstand what you were suggesting here wrt "all
authentication methods"?
Thanks,
Stephen
