On 5/24/23 05:04, Daniel Gustafsson wrote: >> On 23 May 2023, at 23:02, Stephen Frost <sfr...@snowman.net> 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 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