Subject: Re: scram and \password
To: Robert Haas <robertmhaas@gmail.com>
References: <a8b0d5cb-35d4-d686-3fae-f743659ae346@iki.fi>
 <dead641a-1fc8-0fd7-89d6-b818ac61b31a@iki.fi>
 <CAB7nPqQmJ5t=rd67paE7DWxuSi0C4X=5_pnzZchH7qFkBHy==A@mail.gmail.com>
 <CA+TgmoYk+xfnvYC4xtQD4qFdu7xKn6bRLC-baH5MDdtyCSxg6w@mail.gmail.com>
 <f56a2116-a466-ad6c-03d5-413294bfca9f@iki.fi>
 <20170410035323.GA2846583@tornado.leadboat.com>
 <CAB7nPqSbsCBCxy8-DtwzRxYgTnbGUtY4uFEkLQhG=R=uo=g8Fw@mail.gmail.com>
 <66e776c9-e02c-3683-28df-339f7f64ea66@iki.fi>
 <CAB7nPqSWP9J9PzeC7=-WjuuaL57_d+EawmzJNVsM+m7Y4gRRBA@mail.gmail.com>
 <c32a2be9-f25d-30e8-6d48-64e1801a910f@iki.fi>
 <57f8c243-2362-e7b8-4c56-e752ba6edf6c@iki.fi>
 <CA+Tgmob3oL+xLxMgD6zmhhDab62yr67W4bbALT3G_swkG6NmPg@mail.gmail.com>
 <7611.1493225874@sss.pgh.pa.us> <57078b66-4c6d-bd95-5d66-f4c6fc02e8e1@iki.fi>
 <CA+TgmobVav0oLXutZreDLz4fzpWKaPKAjsBcOxBom2+L-3n17A@mail.gmail.com>
 <1fa284d4-6d33-5593-9d97-777ee4d01611@iki.fi>
 <CA+TgmoZ1oCu6pdRaj4sexaSPUooLcgRzrwd6qMV-SB7JsqTAmQ@mail.gmail.com>
From: Heikki Linnakangas <hlinnaka@iki.fi>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Michael Paquier
 <michael.paquier@gmail.com>, Noah Misch <noah@leadboat.com>,
 Jeff Janes <jeff.janes@gmail.com>, Joe Conway <mail@joeconway.com>,
 pgsql-hackers <pgsql-hackers@postgresql.org>
Message-ID: <61a24853-d14b-e3a3-32ba-bd86fe80a475@iki.fi>
Date: Wed, 3 May 2017 11:26:53 +0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101
 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: 
 <CA+TgmoZ1oCu6pdRaj4sexaSPUooLcgRzrwd6qMV-SB7JsqTAmQ@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 05/02/2017 07:47 PM, Robert Haas wrote:
> On Tue, May 2, 2017 at 3:42 AM, Heikki Linnakangas <hlinnaka@iki.fi> wrote:
>> There's going to be a default, one way or another. The default is going to
>> come from password_encryption, or it's going to be a hard-coded value or
>> logic based on server-version in PQencryptPasswordConn(). Or it's going to
>> be a hard-coded value or logic implemented in every application that uses
>> PQencryptPasswordConn(). I think looking at password_encryption makes the
>> most sense. The application is not in a good position to make the decision,
>> and forcing the end-user to choose every time they change a password is too
>> onerous.
>
> I think there should be no default, and the caller should have to pass
> the algorithm explicitly.  If they want to determine what default to
> pass by running 'SHOW password_encryption', that's their choice.

Ok, gotcha. I disagree, I think we should provide a default. Libpq is in 
a better position to make a good choice than most applications.

I've committed the new PQencryptPasswordConn function, with the default 
behavior of doing "show password_encryption", and the changes to use it 
in psql and createuser. This closes the open issue with \password.

On 04/27/2017 07:03 AM, Michael Paquier wrote:
> I think that it is a mistake to move SASLprep out of
> scram_build_verifier, because pre-processing the password is not
> necessary, it is normally mandatory. The BE/FE versions that you are
> adding also duplicate the calls to pg_saslprep().

I played with that a little bit, but decided to keep pg_saslprep() out 
of scram_build_verifier() after all. It would seem asymmetric to have 
scram_build_verifier() call pg_saslprep(), but require callers of 
scram_SaltedPassword() to call it. So for consistency, I think 
scram_SaltedPassword() should also call pg_saslprep(). That would 
complicated the scram_SaltedPassword() function, however. It would need 
to report an OOM error somehow, for starters. Not an insurmountable 
issue, of course, but it felt cleaner this way, after all, despite the 
duplication.

> Using "encrypt" instead of "hash" in the function name :(

Yeah. For better or worse, I've kept the "encrypt" nomenclature 
everywhere, for consistency.

Thanks!

- Heikki


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