Re: Docs: Encourage strong server verification with SCRAM

On 5/24/23 05:04, Daniel Gustafsson wrote:
>> On 23 May 2023, at 23:02, Stephen Frost <sfrost(at)snowman(dot)net> wrote:
>> * Jacob Champion (jchampion(at)timescale(dot)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 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