Message-ID: <55C4FCC2.3000503@iki.fi>
Date: Fri, 07 Aug 2015 21:45:22 +0300
From: Heikki Linnakangas <hlinnaka@iki.fi>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
 rv:31.0) Gecko/20100101 Icedove/31.8.0
MIME-Version: 1.0
To: Robert Haas <robertmhaas@gmail.com>,
 Michael Paquier <michael.paquier@gmail.com>
CC: pgsql-hackers <pgsql-hackers@postgresql.org>
Subject: Re: WIP: SCRAM authentication
References: <55192AFE.6080106@iki.fi>
	<CAB7nPqRB_Z2B7Lz96iHbHUQBQLwmUtj64hXu0u7mMZjpSk8UUg@mail.gmail.com>
	<CAB7nPqRBtLOT=g3q2-uYE=NbBdtkLubvDbV6wfCUp3hubpa6dg@mail.gmail.com>
 <CA+TgmoZ0XxXZeGa0f1uwaCN-FCjFsAJZdJgioeesdhfR7jmEhg@mail.gmail.com>
In-Reply-To: 
 <CA+TgmoZ0XxXZeGa0f1uwaCN-FCjFsAJZdJgioeesdhfR7jmEhg@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org

On 08/07/2015 09:26 PM, Robert Haas wrote:
> Maybe I'm chiming in too late here but I am sorta unimpressed by this.
> If the user's password is stored both MD5-hashed and hashed some other
> way in the system catalogs, that's less secure than storing it in the
> least secure of those ways.  And I'm afraid that if we introduce this
> new mechanism, we won't really gain any security, because everybody
> will just pg_dump or pg_upgrade and the old passwords will stick
> around in the system forever.  In fact we might lose security if
> somebody changes one password verifier but doesn't realize that the
> other one is still floating around, memorializing the old password,
> and still available to be used for login.

Yeah, that's certainly a risk. You wouldn't want to keep around 
verifiers for authentication methods you don't use.

> I think we should look for a solution that either (a) allows SCRAM
> authentication without requiring any changes to the contents of
> pg_authid, like what Heikki proposed before; or (b) forces a hard
> break, where at each password change you can decide if you want the
> old or new format (probably based on the current value of some
> compatibility GUC).

Yeah, something to force a hard break when you want it would be really 
good. Perhaps a command you can run to remove all MD5 hashes, or at 
least find all the roles that have them. And a GUC to disallow creating 
new ones.

- Heikki


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers