On 6/5/23 11:22 AM, Jacob Champion wrote:
On Sat, Jun 3, 2023 at 2:50 PM Michael Paquier wrote:
Took me some time to get back to it, but applied this way.
Thanks all!
+1; thank you!
Jonathan
OpenPGP_signature
Description: OpenPGP digital signature
On Sat, Jun 3, 2023 at 2:50 PM Michael Paquier wrote:
> Took me some time to get back to it, but applied this way.
Thanks all!
--Jacob
On Thu, Jun 01, 2023 at 08:28:32AM -0400, Michael Paquier wrote:
> Hmm. Okay by me.
Took me some time to get back to it, but applied this way.
--
Michael
signature.asc
Description: PGP signature
On Thu, Jun 01, 2023 at 10:22:28AM +0200, Daniel Gustafsson wrote:
> It's true that an attacker kan use offline analysis but it makes it sound
> easier than it might be in practice. I would have written "to potentially
> determine".
Hmm. Okay by me.
--
Michael
signature.asc
Description: PGP si
> On 31 May 2023, at 23:14, Michael Paquier wrote:
> On Wed, May 31, 2023 at 10:08:39AM -0400, Jacob Champion wrote:
>> LGTM!
>
> Okay. Does anybody have any comments and/or objections?
LGTM. As a small nitpick, I think this sentence is a little bit misleading:
"..can use offline ana
On Wed, May 31, 2023 at 10:08:39AM -0400, Jacob Champion wrote:
> LGTM!
Okay. Does anybody have any comments and/or objections?
--
Michael
signature.asc
Description: PGP signature
On Sun, May 28, 2023 at 2:22 PM Jonathan S. Katz wrote:
> The above assumes that the reader reviewed the previous paragraph and
> followed the guidelines there. However, we can make it explicit. Please
> see attached.
LGTM!
Thanks,
--Jacob
On Sun, May 28, 2023 at 02:21:53PM -0400, Jonathan S. Katz wrote:
> The above assumes that the reader reviewed the previous paragraph and
> followed the guidelines there. However, we can make it explicit. Please see
> attached.
Yeah, I was under the same impression as Jacob that we don't insist
en
On 5/26/23 6:47 PM, Jacob Champion wrote:
On Thu, May 25, 2023 at 6:10 PM Jonathan S. Katz wrote:
+ To prevent server spoofing from occurring when using
+ scram-sha-256 password authentication
+ over a network, you should ensure you are connecting using SSL.
seems to backtrack on the
On Thu, May 25, 2023 at 6:10 PM Jonathan S. Katz wrote:
> I read through the proposal and like this much better.
Great!
> I rewrote this to just focus on server spoofing that can occur with
> SCRAM authentication and did some wordsmithing. I was torn on keeping in
> the part of offline analysis
On 5/25/23 3:27 PM, Jacob Champion wrote:
On Thu, May 25, 2023 at 10:48 AM Jonathan S. Katz wrote:
Overall, +1 to tightening the language around the docs in this area.
However, to paraphrase Stephen, I think the language, as currently
written, makes the problem sound scarier than it actually i
existing paragraphs.)
--Jacob
From 96dee3dead97d38afd0d8139f5c9954ab76dfcba Mon Sep 17 00:00:00 2001
From: Jacob Champion
Date: Mon, 22 May 2023 16:46:23 -0700
Subject: [PATCH v2] docs: encourage strong server verification with SCRAM
The server verification in libpq's SCRAM implementation can
On 5/25/23 1:29 PM, Stephen Frost wrote:
Greetings,
* Jacob Champion (jchamp...@timescale.com) wrote:
On 5/24/23 05:04, Daniel Gustafsson wrote:
On 23 May 2023, at 23:02, Stephen Frost wrote:
Perhaps more succinctly- maybe we should be making adjustments to the
current language instead of jus
On Thu, May 25, 2023 at 10:29 AM Stephen Frost wrote:
> I was referring specifically to that ordering as not being ideal or in
> line with the rest of the flow of that section. We should integrate the
> concerns higher in the section where we outline the reason these things
> matter and then foll
Greetings,
* Jacob Champion (jchamp...@timescale.com) wrote:
> On 5/24/23 05:04, Daniel Gustafsson wrote:
> >> On 23 May 2023, at 23:02, Stephen Frost wrote:
> >> Perhaps more succinctly- maybe we should be making adjustments to the
> >> current language instead of just adding a new paragraph.
>
On 5/23/23 21:37, Michael Paquier wrote:
> On Tue, May 23, 2023 at 10:01:03PM -0400, Stephen Frost wrote:
>> To the extent that there was an issue when it was implemented ... it's
>> now been implemented and so that was presumably overcome (though I don't
>> really specifically recall what the issu
On 5/24/23 05:04, Daniel Gustafsson wrote:
>> On 23 May 2023, at 23:02, Stephen Frost wrote:
>> * Jacob Champion (jchamp...@timescale.com) wrote:
>
>>> - low iteration counts accepted by the client make it easier than it
>>> probably should be for a MITM to brute-force passwords (note that
>>> PG
> On 23 May 2023, at 23:02, Stephen Frost wrote:
> * Jacob Champion (jchamp...@timescale.com) wrote:
>> - low iteration counts accepted by the client make it easier than it
>> probably should be for a MITM to brute-force passwords (note that
>> PG16's scram_iterations GUC, being server-side, does
On Tue, May 23, 2023 at 10:01:03PM -0400, Stephen Frost wrote:
> To the extent that there was an issue when it was implemented ... it's
> now been implemented and so that was presumably overcome (though I don't
> really specifically recall what the issues were there? Seems like it
> wouldn't matte
Greetings,
* Michael Paquier (mich...@paquier.xyz) wrote:
> On Tue, May 23, 2023 at 09:46:58PM -0400, Stephen Frost wrote:
> > Not without breaking things we support today and for what seems like an
> > unclear benefit given that we've got channel binding today (though
> > perhaps we need to make
On Tue, May 23, 2023 at 09:46:58PM -0400, Stephen Frost wrote:
> Not without breaking things we support today and for what seems like an
> unclear benefit given that we've got channel binding today (though
> perhaps we need to make sure there's ways to force it on both sides to
> be on and to encou
Greetings,
* Michael Paquier (mich...@paquier.xyz) wrote:
> On Tue, May 23, 2023 at 05:02:50PM -0400, Stephen Frost wrote:
> > * Jacob Champion (jchamp...@timescale.com) wrote:
> >> As touched on in past threads, our SCRAM implementation is slightly
> >> nonstandard and doesn't always protect the
On Tue, May 23, 2023 at 05:02:50PM -0400, Stephen Frost wrote:
> * Jacob Champion (jchamp...@timescale.com) wrote:
>> As touched on in past threads, our SCRAM implementation is slightly
>> nonstandard and doesn't always protect the entirety of the
>> authentication handshake:
>>
>> - the username i
Greetings,
* Jacob Champion (jchamp...@timescale.com) wrote:
> As touched on in past threads, our SCRAM implementation is slightly
> nonstandard and doesn't always protect the entirety of the
> authentication handshake:
>
> - the username in the startup packet is not covered by the SCRAM
> crypto
ll out that GSS can't use channel binding,
or promote the use of TLS versus GSS for SCRAM, or just keep it
simple?
Thanks,
--Jacob
From 5b346313f1cecd3c4c79b6e104094e50bb1cfa75 Mon Sep 17 00:00:00 2001
From: Jacob Champion
Date: Mon, 22 May 2023 16:46:23 -0700
Subject: [PATCH] docs: encourage
25 matches
Mail list logo
