* Jim Nasby (Jim.Nasby@BlueTreble.com) wrote:
> On 3/4/15 2:56 PM, Stephen Frost wrote:
> >>2) The per-session salt sent to the client is only 32-bits, meaning
> >>>that it is possible to reply an observed MD5 hash in ~16k connection
> >>>attempts.
> >Yes, and we have no (PG-based) mechanism to prevent those connection
> >attempts, which is a pretty horrible situation to be in.
>
> Is there some reason we don't just fix that? I'm thinking that this
> is a special case where we could just modify the pg_auth tuple
> in-place without bloating the catalog (we already do that somewhere
> else). Is there something else that makes this difficult? Are we
> afraid of an extra GUC to control it?
I'm all for it, though I would ask that we provide a way for superusers
to delegate the ability to reset locked accounts to non-superusers.
I'd want to think about it a bit more before settling on using pg_authid
to track the data. In any case, I do think we need a way to disable
this ability for certain roles and, furtherr, that we not track failed
logins in cases where it's disabled (which might well be the default- I
don't think we want to add this overhead for systems which have lots of
recurring logins (think application users where they aren't doing
pooling).
Thanks!
Stephen