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
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?
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http://BlueTreble.com
Sent via pgsql-hackers mailing list (email@example.com)
To make changes to your subscription: