Greetings, * Tom Lane (t...@sss.pgh.pa.us) wrote: > Stephen Frost <sfr...@snowman.net> writes: > > 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. > > What problem do we actually need to solve here? > > If the known use-case is just "don't send my password in the clear", > maybe we should just change libpq to refuse to do that, ie reject > plain-password auth methods unless SSL is on (except maybe over > unix sockets?). Or invent a bool connection option that enables > exactly that.
Right, inventing a bool connection for it was discussed up-thread and seems like a reasonable idea to me (note: we should absolutely allow the user to refuse to send the password to the server even over SSL, if they would prefer to not do so). > I'm not really convinced that there is a use-case for client side > specification of allowed auth methods beyond that. In the end, > if you don't trust the server you're connecting to to handle your > password with reasonable safety, you have got bigger problems than > this one. And we already have coverage for MITM problems (or if > we don't, this sideshow isn't fixing it). Uh, no, we really don't have MITM protection in certain cases, which is exactly what channel-binding is intended to address, but we can't have the "server" be able to say "oh, well, I don't support channel binding" and have the client go "oh, ok, that's just fine, we won't use it then"- that's a downgrade attack. What was suggest up-thread to deal with that downgrade risk was a clear connection option along the lines of "require channel binding" to prevent that kind of a MITM downgrade attack from working. I could possibly see some value in a client-side option along the lines of "only authenticate using GSSAPI", which could prevent some users from being fooled into sending their PW to a malicious server. GSSAPI does prevent MITM attacks (as much as it's able to anyway- each key is specific to a particular server, so you'd have to have the specific server's key in order to become a MITM), but if the server says "we don't do GSSAPI, we do password, please give us your password" then psql will happily go along with that even in an otherwise properly set up GSSAPI environment. Requiring GSSAPI Encryption on the client side should prevent that though, as of v12, since psql will just refuse if the server claims to not support GSSAPI Encryption. Thanks, Stephen
signature.asc
Description: PGP signature
