On 3/5/15 2:17 PM, Stephen Frost wrote:
* Jim Nasby (jim.na...@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
I guess it's a question of how durable we want it to be. We could
conceivable keep it in shared memory and let it wipe on a crash.
But we already have code that ignores MVCC on a catalog table (IIRC for
updating pg_class stats after vacuum) so the pattern is there. I don't
see that we need more sophistication than that...
to track the data. In any case, I do think we need a way to disable
this ability for certain roles
In the interest of something for this release... do we really need that?
My thought is we just special-case the postgres user and be done with
it. Though, if there's some other way to reset an account from the
shell, no need to even special case postgres.
Though, I guess if we just follow the normal GUC behavior of allowing
per-database and -user overrides it wouldn't be that hard.
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).
Yeah, presumably if allowed_authentication_failures < 0 then we don't
bother with the check at all.
--
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http://BlueTreble.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
