public inbox for [email protected]  

help / color / mirror / Atom feed

From: Jacob Champion <[email protected]>
To: Daniel Gustafsson <[email protected]>
To: Stephen Frost <[email protected]>
Cc: PostgreSQL Hackers <[email protected]>
Cc: Jonathan S. Katz <[email protected]>
Cc: Michael Paquier <[email protected]>
Subject: Re: Docs: Encourage strong server verification with SCRAM
Date: Thu, 25 May 2023 09:40:16 -0700
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
References: <CAAWbhmg5Gh0JetNbQi7z0yOsdsN9YECv8GoY-QBGBBiip9+JOw@mail.gmail.com>
	<ZG0p+sk/[email protected]>
	<[email protected]>

On 5/24/23 05:04, Daniel Gustafsson wrote:
>> On 23 May 2023, at 23:02, Stephen Frost <[email protected]> wrote:
>> * Jacob Champion ([email protected]) 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 not mitigate
>>> this)
>>
>> This would be good to improve on.
> 
> The mechanics of this are quite straighforward, the problem IMHO lies in how to
> inform and educate users what a reasonable iteration count is, not to mention
> what an iteration count is in the first place.

Yeah, the education around this is tricky.
>> Perhaps more succinctly- maybe we should be making adjustments to the
>> current language instead of just adding a new paragraph.
> 
> +1

I'm 100% on board for doing that as well, but the "instead of"
suggestion makes me think I didn't explain my goal very well. For
example, Stephen, you said

> I have to admit that the patch as presented strikes me as a warning
> without really providing steps for how to address the issues mentioned
> though; there's a reference to what was just covered at the bottom but
> nothing really new.

but the last sentence of my patch *is* the suggested step:

> +      ... It's recommended to employ strong server
> +      authentication, using one of the above anti-spoofing measures, to prevent
> +      these attacks.

In other words: if you're thinking about authenticating the server via
SCRAM, over an otherwise anonymous key exchange, you should probably
reconsider. The current architecture of libpq doesn't really seem to be
set up for this, and my conversations with security@ have been focusing
around the argument that people who want strong guarantees should be
authenticating the server using a TLS certificate before doing anything
else, so we don't need to consider our departures from the spec to be
vulnerabilities. I think that's a reasonable stance to take, as long as
we're also explicitly warning people away from the mutual-auth use case.

To change this, aspects of the code that we don't currently consider
security problems would probably need to be reclassified. If we're
depending on SCRAM for server authentication, we can't trust a single
byte that the server sends to us until after the SCRAM verifier comes
back and checks out. Compared to all the other authentication types,
that's unusual; I don't think it's really been a focus for the project
before.

--Jacob

view thread (4+ messages)

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
  Subject: Re: Docs: Encourage strong server verification with SCRAM
  In-Reply-To: <[email protected]>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox