Re: Proposal: Support custom authentication methods using hooks,Re: Proposal: Support custom authentication methods using hooks
On Fri, Mar 4, 2022 at 6:03 PM Tatsuo Ishii wrote: > > >> I still don't understand why using plaintex password authentication > >> over SSL connection is considered insecure. Actually we have been > >> stating opposite in the manual: > >> https://www.postgresql.org/docs/14/auth-password.html > >> > >> "If the connection is protected by SSL encryption then password can be > >> used safely, though." > > > > If you aren't doing client verification (i.e., cert in pg_hba) and are > > not doing verify-full on the client side then a man-in-the-middle > > attack on TLS is trivial, and the plaintext password will be > > sniffable. > > So the plaintext password is safe if used with hostssl + verify-full > (server side) and sslmode = verify-full (client side), right? > That would be safe-in-transit so long as everything was configured properly and all certificates were protected. Unfortunately PG doesn't make this incredibly easy to implement, it allows only 1 client root cert, the client side doesn't understand system certificate stores or PKI, etc. Further, if someone gains access to the password hashes there is still a pass-the-hash vulnerability, though.
Re: Proposal: Support custom authentication methods using hooks,Re: Proposal: Support custom authentication methods using hooks
>> I still don't understand why using plaintex password authentication >> over SSL connection is considered insecure. Actually we have been >> stating opposite in the manual: >> https://www.postgresql.org/docs/14/auth-password.html >> >> "If the connection is protected by SSL encryption then password can be >> used safely, though." > > If you aren't doing client verification (i.e., cert in pg_hba) and are > not doing verify-full on the client side then a man-in-the-middle > attack on TLS is trivial, and the plaintext password will be > sniffable. So the plaintext password is safe if used with hostssl + verify-full (server side) and sslmode = verify-full (client side), right? Best reagards, -- Tatsuo Ishii SRA OSS, Inc. Japan English: http://www.sraoss.co.jp/index_en.php Japanese:http://www.sraoss.co.jp
Re: Proposal: Support custom authentication methods using hooks,Re: Proposal: Support custom authentication methods using hooks
On Thu, Mar 3, 2022 at 11:50 PM Tatsuo Ishii wrote: > > >> So, dropping plaintext password authentication support from libpq will > >> make it impossible for users to use the former method. > > > > Yes, just like dropping support for md5 would make it impossible for > > users to have their passwords be hashed with md5, which is an altogether > > good thing considering how easy it is to brute-force md5 these days. > > I still don't understand why using plaintex password authentication > over SSL connection is considered insecure. Actually we have been > stating opposite in the manual: > https://www.postgresql.org/docs/14/auth-password.html > > "If the connection is protected by SSL encryption then password can be > used safely, though." If you aren't doing client verification (i.e., cert in pg_hba) and are not doing verify-full on the client side then a man-in-the-middle attack on TLS is trivial, and the plaintext password will be sniffable. The documentation should be updated to say under no circumstances is this safe.
Re: Proposal: Support custom authentication methods using hooks,Re: Proposal: Support custom authentication methods using hooks
>> So, dropping plaintext password authentication support from libpq will >> make it impossible for users to use the former method. > > Yes, just like dropping support for md5 would make it impossible for > users to have their passwords be hashed with md5, which is an altogether > good thing considering how easy it is to brute-force md5 these days. I still don't understand why using plaintex password authentication over SSL connection is considered insecure. Actually we have been stating opposite in the manual: https://www.postgresql.org/docs/14/auth-password.html "If the connection is protected by SSL encryption then password can be used safely, though." Best reagards, -- Tatsuo Ishii SRA OSS, Inc. Japan English: http://www.sraoss.co.jp/index_en.php Japanese:http://www.sraoss.co.jp
Re: Proposal: Support custom authentication methods using hooks,Re: Proposal: Support custom authentication methods using hooks
Greetings, * Tatsuo Ishii (is...@sraoss.co.jp) wrote: > > On 2/25/22 12:39 PM, Tom Lane wrote: > >> Jeff Davis writes: > >>> On Thu, 2022-02-24 at 20:47 -0500, Tom Lane wrote: > ... and, since we can't readily enforce that the client only sends > those cleartext passwords over suitably-encrypted connections, this > could easily be a net negative for security. Not sure that I think > it's a good idea. > >> > >>> I don't understand your point. Can't you just use "hostssl" rather > >>> than > >>> "host"? > >> My point is that sending cleartext passwords over the wire is an > >> insecure-by-definition protocol that we shouldn't be encouraging > >> more use of. > > > > This is my general feeling as well. We just spent a bunch of effort > > adding, refining, and making SCRAM the default method. I think doing > > anything that would drive more use of sending plaintext passwords, > > even over TLS, is counter to that. > > There's at least one use case to use plaintext passwords. Pgpool-II > accepts plaintext passwords from frontend (from frontend's point of > view, it looks as if the frontend speaks with PostgreSQL server which > requests the plaintext password authentication), then negotiates with > backends regarding authentication method they demand. Suppose we have > 2 PostgreSQL clusters and they require md5 auth. They send different > password encryption salt and Pgpool-II deal with each server using the > salt and password. So Pgpool-II needs plaintext password. Same thing > can be said to SCRAM-SHA-256 authentication because it's kind of > challenge/response based authentication. Passing around plaintext passwords isn't good, regardless of what's doing it. That some things do that today is a problem, not something that should be held up as an example use-case that we should be retaining support for. > Actually it is possible for Pgpool-II to not use plaintext passwords > reading from frontend. In this case passwords are stored in a file and > Pgpool-II reads passwords from the file. But this is annoying for > users because they have to sync the passwords stored in PostgreSQL > with the passwords stored in the file. Users authenticating to an application and then independently having applications authenticate to the database server is actually rather common. I agree that proxying credentials is generally better and I'm hoping to commit support for exactly that during this CF for GSSAPI (aka Kerberos), where it's cleanly supported. Proxying using plaintext passwords isn't good though. > So, dropping plaintext password authentication support from libpq will > make it impossible for users to use the former method. Yes, just like dropping support for md5 would make it impossible for users to have their passwords be hashed with md5, which is an altogether good thing considering how easy it is to brute-force md5 these days. Thanks, Stephen signature.asc Description: PGP signature
Re: Proposal: Support custom authentication methods using hooks,Re: Proposal: Support custom authentication methods using hooks
> On 2/25/22 12:39 PM, Tom Lane wrote: >> Jeff Davis writes: >>> On Thu, 2022-02-24 at 20:47 -0500, Tom Lane wrote: ... and, since we can't readily enforce that the client only sends those cleartext passwords over suitably-encrypted connections, this could easily be a net negative for security. Not sure that I think it's a good idea. >> >>> I don't understand your point. Can't you just use "hostssl" rather >>> than >>> "host"? >> My point is that sending cleartext passwords over the wire is an >> insecure-by-definition protocol that we shouldn't be encouraging >> more use of. > > This is my general feeling as well. We just spent a bunch of effort > adding, refining, and making SCRAM the default method. I think doing > anything that would drive more use of sending plaintext passwords, > even over TLS, is counter to that. There's at least one use case to use plaintext passwords. Pgpool-II accepts plaintext passwords from frontend (from frontend's point of view, it looks as if the frontend speaks with PostgreSQL server which requests the plaintext password authentication), then negotiates with backends regarding authentication method they demand. Suppose we have 2 PostgreSQL clusters and they require md5 auth. They send different password encryption salt and Pgpool-II deal with each server using the salt and password. So Pgpool-II needs plaintext password. Same thing can be said to SCRAM-SHA-256 authentication because it's kind of challenge/response based authentication. Actually it is possible for Pgpool-II to not use plaintext passwords reading from frontend. In this case passwords are stored in a file and Pgpool-II reads passwords from the file. But this is annoying for users because they have to sync the passwords stored in PostgreSQL with the passwords stored in the file. So, dropping plaintext password authentication support from libpq will make it impossible for users to use the former method. Best reagards, -- Tatsuo Ishii SRA OSS, Inc. Japan English: http://www.sraoss.co.jp/index_en.php Japanese:http://www.sraoss.co.jp
