On Fri, Jul 14, 2017 at 7:48 AM, Vladimir Borodin wrote:
>
> 14 июля 2017 г., в 1:33, Stephen Frost написал(а):
>
> What would be really nice for such cases is support for Kerberos and
> delegated Kerberos credentials. Having pgpool support that would remove
> the need to deal with passwords at
On Sat, Jul 15, 2017 at 12:15 AM, Stephen Frost wrote:
> While this might be possible by having some kind of special trusted
> connection between the pooler and PG, I actually don't particularly like
> the notion of inventing a bunch of complicated logic and pain so that a
> connection pooler can
Greetings,
* Vladimir Borodin (r...@simply.name) wrote:
> > 14 июля 2017 г., в 1:33, Stephen Frost написал(а):
> > What would be really nice for such cases is support for Kerberos and
> > delegated Kerberos credentials. Having pgpool support that would remove
> > the need to deal with passwords
> 14 июля 2017 г., в 1:33, Stephen Frost написал(а):
>
> What would be really nice for such cases is support for Kerberos and
> delegated Kerberos credentials. Having pgpool support that would remove
> the need to deal with passwords at all.
Since nearly all systems with some kind of load nowa
On 07/13/2017 10:46 PM, Chapman Flack wrote:
> Neither is suitable on an unencrypted channel (as has been repeatedly
Please forgive my thinko about md5. I had overlooked the second
salted md5 used in the protocol, and that had to be some years ago
when I was sure I had looked for one in the code.
On 07/13/17 21:54, Tatsuo Ishii wrote:
>>> The comment in pg_hba.conf.sample seem to prefer md5 over clear text
>>> password.
>>>
>>> # Note that "password" sends passwords in clear text; "md5" or
>>> # "scram-sha-256" are preferred since they send encrypted passwords.
>>
>> Should that be reworded
>> The comment in pg_hba.conf.sample seem to prefer md5 over clear text
>> password.
>>
>> # Note that "password" sends passwords in clear text; "md5" or
>> # "scram-sha-256" are preferred since they send encrypted passwords.
>
> Should that be reworded to eliminate "md5"? I'd consider "scram-sha
On 07/13/17 20:09, Tatsuo Ishii wrote:
> The comment in pg_hba.conf.sample seem to prefer md5 over clear text
> password.
>
> # Note that "password" sends passwords in clear text; "md5" or
> # "scram-sha-256" are preferred since they send encrypted passwords.
Should that be reworded to eliminate
>> Using a clear text password would not be acceptable for users even
>> through an encrypted connection, I think.
>
> Really, I don't think users who are concerned with security should be
> using the md5 method either.
The comment in pg_hba.conf.sample seem to prefer md5 over clear text
password
Greetings Tatsuo,
* Tatsuo Ishii (is...@sraoss.co.jp) wrote:
> > What I am suggesting here is that in order to handle properly SCRAM
> > with channel binding, pgpool has to provide a different handling for
> > client <-> pgpool and pgpool <-> Postgres. In short, I don't have a
> > better answer th
> What I am suggesting here is that in order to handle properly SCRAM
> with channel binding, pgpool has to provide a different handling for
> client <-> pgpool and pgpool <-> Postgres. In short, I don't have a
> better answer than having pgpool impersonate the server and request
> for a password i
On Sat, Jul 8, 2017 at 1:54 PM, Álvaro Hernández Tortosa
wrote:
> There's definitely an important concern here that should be addressed:
> how poolers/proxies/middleware/etc can deal with SCRAM, specifically in the
> context of channel binding.
>
> If there is to be a single connection fr
On Sat, Jul 8, 2017 at 9:30 AM, Stephen Frost wrote:
> Michael,
>
> * Michael Paquier (michael.paqu...@gmail.com) wrote:
>> On Sat, Jul 8, 2017 at 1:24 AM, Robert Haas wrote:
>> > IIUC, things will get even worse once channel binding is committed,
>> > presumably for PostgreSQL 11. The point of
Hi Alvaro,
> Hi Tatsuo.
>
> There's definitely an important concern here that should be addressed:
> how poolers/proxies/middleware/etc can deal with SCRAM, specifically
> in the context of channel binding.
>
> If there is to be a single connection from client to PostgreSQL
>
On 06/07/17 04:03, Tatsuo Ishii wrote:
Hi PostgreSQL hackers,
I would like to hear ideas how Pgpool-II can deal with SCRAM auth
which will be in PostgreSQL 10.
For those who are not familiar with Pgpool-II[1], it is an external
OSS project to provide some additional features to PostgreSQL,
in
>> For more details what Pgpool-II actually does in md5 auth, please see:
>>
>> https://pgpool.net/mediawiki/index.php/FAQ#How_does_pgpool-II_handle_md5_authentication.3F
>
> I see. In short, that's not going to be able to work with SCRAM.
That's my understanding with SCRAM too.
> We also cert
Tatsuo,
* Tatsuo Ishii (is...@sraoss.co.jp) wrote:
> > I recall vaguely Ishii-san mentioning me at PGcon that pgpool was
> > actually cheating, but my memories are a bit fuzzy for this part.
>
> What I meant by "cheating" was, Pgpool-II behaves as if PostgreSQL
> server in md5 auth.
>
> For more
Michael,
* Michael Paquier (michael.paqu...@gmail.com) wrote:
> On Sat, Jul 8, 2017 at 1:24 AM, Robert Haas wrote:
> > IIUC, things will get even worse once channel binding is committed,
> > presumably for PostgreSQL 11. The point of channel binding is to
> > guarantee that you are conducting th
> I recall vaguely Ishii-san mentioning me at PGcon that pgpool was
> actually cheating, but my memories are a bit fuzzy for this part.
What I meant by "cheating" was, Pgpool-II behaves as if PostgreSQL
server in md5 auth.
For more details what Pgpool-II actually does in md5 auth, please see:
ht
> I think it is. From a security point of view, the fact that the same
> salt is always used for the same username is a weakness of md5
> authentication which SCRAM corrects.
In my understanding, md5 does not always use the same salt for the
same username. PostgreSQL keeps md5(password+username)
On Sat, Jul 8, 2017 at 1:24 AM, Robert Haas wrote:
> On Wed, Jul 5, 2017 at 9:32 PM, Michael Paquier
> wrote:
>> On Thu, Jul 6, 2017 at 10:03 AM, Tatsuo Ishii wrote:
>>> For Pgpool-II, things would go as follows:
>>>
>>> 1) clients sends user name to Pgpool-II.
>>> 2) Pgpool-II forwards it to Po
On Thu, Jul 06, 2017 at 10:03:37AM +0900, Tatsuo Ishii wrote:
> Hi PostgreSQL hackers,
>
> I would like to hear ideas how Pgpool-II can deal with SCRAM auth
> which will be in PostgreSQL 10.
>
> For those who are not familiar with Pgpool-II[1], it is an external
> OSS project to provide some addi
On Wed, Jul 5, 2017 at 9:32 PM, Michael Paquier
wrote:
> On Thu, Jul 6, 2017 at 10:03 AM, Tatsuo Ishii wrote:
>> For Pgpool-II, things would go as follows:
>>
>> 1) clients sends user name to Pgpool-II.
>> 2) Pgpool-II forwards it to PostgreSQL servers.
>> 3) Each PostgreSQL server sends their ow
Michael,
> Couldn't you cache one single SASL exchange status for each
> connection, meaning one PGconn saved for each? As the challenge sent
> by the server and the response generated by the client are different
> by design, I am afraid you would need to do that anyway in this
> context (Isn't PG
On Thu, Jul 6, 2017 at 10:03 AM, Tatsuo Ishii wrote:
> For Pgpool-II, things would go as follows:
>
> 1) clients sends user name to Pgpool-II.
> 2) Pgpool-II forwards it to PostgreSQL servers.
> 3) Each PostgreSQL server sends their own salt to Pgpool-II.
> 4) Pgpool-II is confused because there a
Hi PostgreSQL hackers,
I would like to hear ideas how Pgpool-II can deal with SCRAM auth
which will be in PostgreSQL 10.
For those who are not familiar with Pgpool-II[1], it is an external
OSS project to provide some additional features to PostgreSQL,
including load balancing and automatic failov
26 matches
Mail list logo