Message-ID: <54F8C3B8.5070802@BlueTreble.com>
Date: Thu, 5 Mar 2015 14:59:36 -0600
From: Jim Nasby <Jim.Nasby@BlueTreble.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9;
 rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To: Stephen Frost <sfrost@snowman.net>
CC: Bruce Momjian <bruce@momjian.us>, PostgreSQL-development
 <pgsql-hackers@postgreSQL.org>
Subject: Re: MD5 authentication needs help
References: <20150304174354.GC29780@tamriel.snowman.net>
 <20150304175857.GA31979@momjian.us>
 <20150304182731.GG29780@tamriel.snowman.net>
 <20150304191625.GB31979@momjian.us>
 <20150304192151.GJ29780@tamriel.snowman.net>
 <20150304193715.GC31979@momjian.us>
 <20150304194654.GL29780@tamriel.snowman.net>
 <20150304204327.GD31979@momjian.us>
 <20150304205603.GM29780@tamriel.snowman.net>
 <54F8B7FD.8070706@BlueTreble.com>
 <20150305201756.GG29780@tamriel.snowman.net>
In-Reply-To: <20150305201756.GG29780@tamriel.snowman.net>
Content-Type: text/plain; charset="windows-1252"; format=flowed
Content-Transfer-Encoding: 7bit
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 Mar 2015 20:59:48.3905 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR11MB0347
X-Pg-Spam-Score: -1.9 (-)
List-Archive: <http://archives.postgresql.org/pgsql-hackers>
List-Help: <mailto:majordomo@postgresql.org?body=help>
List-ID: <pgsql-hackers.postgresql.org>
List-Owner: <mailto:pgsql-hackers-owner@postgresql.org>
List-Post: <mailto:pgsql-hackers@postgresql.org>
List-Subscribe: <mailto:majordomo@postgresql.org?body=sub%20pgsql-hackers>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-hackers>
X-Mailing-List: pgsql-hackers
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org

On 3/5/15 2:17 PM, Stephen Frost wrote:
> * 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

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