pgsql: Allow SCRAM authentication, when pg_hba.conf says 'md5'.

From: Heikki Linnakangas <heikki(dot)linnakangas(at)iki(dot)fi>
To: pgsql-committers(at)postgresql(dot)org
Subject: pgsql: Allow SCRAM authentication, when pg_hba.conf says 'md5'.
Date: 2017-03-24 11:34:49
Message-ID: E1crNUX-0004uA-Md@gemulon.postgresql.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers

Allow SCRAM authentication, when pg_hba.conf says 'md5'.

If a user has a SCRAM verifier in pg_authid.rolpassword, there's no reason
we cannot attempt to perform SCRAM authentication instead of MD5. The worst
that can happen is that the client doesn't support SCRAM, and the
authentication will fail. But previously, it would fail for sure, because
we would not even try. SCRAM is strictly more secure than MD5, so there's
no harm in trying it. This allows for a more graceful transition from MD5
passwords to SCRAM, as user passwords can be changed to SCRAM verifiers
incrementally, without changing pg_hba.conf.

Refactor the code in auth.c to support that better. Notably, we now have to
look up the user's pg_authid entry before sending the password challenge,
also when performing MD5 authentication. Also simplify the concept of a
"doomed" authentication. Previously, if a user had a password, but it had
expired, we still performed SCRAM authentication (but always returned error
at the end) using the salt and iteration count from the expired password.
Now we construct a fake salt, like we do when the user doesn't have a
password or doesn't exist at all. That simplifies get_role_password(), and
we can don't need to distinguish the "user has expired password", and
"user does not exist" cases in auth.c.

On second thoughts, also rename uaSASL to uaSCRAM. It refers to the
mechanism specified in pg_hba.conf, and while we use SASL for SCRAM
authentication at the protocol level, the mechanism should be called SCRAM,
not SASL. As a comparison, we have uaLDAP, even though it looks like the
plain 'password' authentication at the protocol level.

Discussion: https://www.postgresql.org/message-id/6425.1489506016@sss.pgh.pa.us
Reviewed-by: Michael Paquier

Branch
------
master

Details
-------
http://git.postgresql.org/pg/commitdiff/7ac955b34791500069179e1ea986f46d510126d9

Modified Files
--------------
doc/src/sgml/client-auth.sgml | 37 +++---
src/backend/libpq/auth-scram.c | 104 +++++++++--------
src/backend/libpq/auth.c | 179 +++++++++++++++++++-----------
src/backend/libpq/crypt.c | 44 +++-----
src/backend/libpq/hba.c | 2 +-
src/include/libpq/crypt.h | 3 +-
src/include/libpq/hba.h | 2 +-
src/include/libpq/scram.h | 2 +-
src/test/authentication/t/001_password.pl | 6 +-
9 files changed, 214 insertions(+), 165 deletions(-)

Browse pgsql-committers by date

  From Date Subject
Next Message Dave Page 2017-03-24 11:35:19 Re: [COMMITTERS] pgsql: Fix and simplify check for whether we're running as Windows serv
Previous Message Teodor Sigaev 2017-03-24 10:55:45 pgsql: Fix backup canceling