Add scramMaxIterations option to limit SCRAM iteration count

[sehrope]

Caps the number of SCRAM iterations the driver will perform during SASL auth, defaulting to 100000. Protects against malicious or misconfigured servers requesting unbounded PBKDF2 work. A value of zero disables the check entirely.

---

Went back and forth on adding it to the continueSession(...) vs startSession(...). Ended up going with this approach as it makes it a bit easier to test the defaults and overrides.

We added something similar to this to Java driver pgjdbc recently with the same 100K default.

[charmander]

Is session.scramMaxIterations always a number here (at least when used via Client)? If so, I think omitting the check makes sense. (And if supporting direct use really is a goal, startSession seems like the place to do it.)

[sehrope]

Yes it should always be a number as we do the coerceNumberOrDefault(...).

That would simplify it a bit as the only place it's set is in startSession and this part would be just:

  // a value of 0 disables the iteration count check
  if (this.scramMaxIterations !== 0 && sv.iteration > this.scramMaxIterations) {
    throw new Error(
      'SASL: SCRAM-SERVER-FIRST-MESSAGE: iteration count ' +
        sv.iteration +
        ' exceeds scramMaxIterations of ' +
        this.scramMaxIterations
    )
  }

[sehrope]

Oh wait I realize now that I did it like this because a bunch of the tests create their own session objects and call the other sasl functions:

sasl.continueSession(
    {
      message: 'SASLInitialResponse',
      clientNonce: 'a',
    },
    badPasswordValue,
    'r=1,i=1'
  ),
  {
    message: 'SASL: SCRAM-SERVER-FIRST-MESSAGE: client password must be a string',
  }
)

So it wouldn't always be populated unless we update all the tests to add the default.

[charmander]

Maybe a shared wrapper function for test use that’s more faithful to how Client will use it?