database/postgres
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2025-10-25 13:17:41 +03:00
Code Activity

Support SCRAM-SHA-256 authentication (RFC 5802 and 7677).

Browse Source 
This introduces a new generic SASL authentication method, similar to the
GSS and SSPI methods. The server first tells the client which SASL
authentication mechanism to use, and then the mechanism-specific SASL
messages are exchanged in AuthenticationSASLcontinue and PasswordMessage
messages. Only SCRAM-SHA-256 is supported at the moment, but this allows
adding more SASL mechanisms in the future, without changing the overall
protocol.

Support for channel binding, aka SCRAM-SHA-256-PLUS is left for later.

The SASLPrep algorithm, for pre-processing the password, is not yet
implemented. That could cause trouble, if you use a password with
non-ASCII characters, and a client library that does implement SASLprep.
That will hopefully be added later.

Authorization identities, as specified in the SCRAM-SHA-256 specification,
are ignored. SET SESSION AUTHORIZATION provides more or less the same
functionality, anyway.

If a user doesn't exist, perform a "mock" authentication, by constructing
an authentic-looking challenge on the fly. The challenge is derived from
a new system-wide random value, "mock authentication nonce", which is
created at initdb, and stored in the control file. We go through these
motions, in order to not give away the information on whether the user
exists, to unauthenticated users.

Bumps PG_CONTROL_VERSION, because of the new field in control file.

Patch by Michael Paquier and Heikki Linnakangas, reviewed at different
stages by Robert Haas, Stephen Frost, David Steele, Aleksander Alekseev,
and many others.

Discussion: https://www.postgresql.org/message-id/CAB7nPqRbR3GmFYdedCAhzukfKrgBLTLtMvENOmPrVWREsZkF8g%40mail.gmail.com
Discussion: https://www.postgresql.org/message-id/CAB7nPqSMXU35g%3DW9X74HVeQp0uvgJxvYOuA4A-A3M%2B0wfEBv-w%40mail.gmail.com
Discussion: https://www.postgresql.org/message-id/55192AFE.6080106@iki.fi
This commit is contained in:
Heikki Linnakangas
2017-03-07 14:25:40 +02:00
parent 273c458a2b
commit 818fd4a67d
38 changed files with 2866 additions and 77 deletions
Download Patch File Download Diff File Expand all files Collapse all files

59
doc/src/sgml/client-auth.sgml
View File

@@ -422,6 +422,17 @@ hostnossl <replaceable>database</replaceable> <replaceable>user</replaceable>
</listitem>
</varlistentry>
<varlistentry>
<term><literal>scram</></term>
<listitem>
<para>
Perform SCRAM-SHA-256 authentication to verify the user's
password.
See <xref linkend="auth-password"> for details.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term><literal>password</></term>
<listitem>
@@ -673,13 +684,19 @@ host postgres all 192.168.93.0/24 ident
# "postgres" if the user's password is correctly supplied.
#
# TYPE DATABASE USER ADDRESS METHOD
host postgres all 192.168.12.10/32 md5
host postgres all 192.168.12.10/32 scram
# Allow any user from hosts in the example.com domain to connect to
# any database if the user's password is correctly supplied.
#
# Most users use SCRAM authentication, but some users use older clients
# that don't support SCRAM authentication, and need to be able to log
# in using MD5 authentication. Such users are put in the @md5users
# group, everyone else must use SCRAM.
#
# TYPE DATABASE USER ADDRESS METHOD
host all all .example.com md5
host all @md5users .example.com md5
host all all .example.com scram
# In the absence of preceding "host" lines, these two lines will
# reject all connections from 192.168.54.1 (since that entry will be
@@ -907,21 +924,37 @@ omicron bryanh guest1
</indexterm>
<para>
The password-based authentication methods are <literal>md5</>
and <literal>password</>. These methods operate
The password-based authentication methods are <literal>scram</>
<literal>md5</> and <literal>password</>. These methods operate
similarly except for the way that the password is sent across the
connection, namely MD5-hashed and clear-text respectively.
connection.
</para>
<para>
If you are at all concerned about password
<quote>sniffing</> attacks then <literal>md5</> is preferred.
Plain <literal>password</> should always be avoided if possible.
However, <literal>md5</> cannot be used with the <xref
linkend="guc-db-user-namespace"> feature. If the connection is
protected by SSL encryption then <literal>password</> can be used
safely (though SSL certificate authentication might be a better
choice if one is depending on using SSL).
Plain <literal>password</> sends the password in clear-text, and is
therefore vulnerable to password <quote>sniffing</> attacks. It should
always be avoided if possible. If the connection is protected by SSL
encryption then <literal>password</> can be used safely, though.
(Though SSL certificate authentication might be a better choice if one
is depending on using SSL).
</para>
<para>
<literal>scram</> performs SCRAM-SHA-256 authentication, as described
in <ulink url="https://tools.ietf.org/html/rfc5802">RFC5802</ulink>. It
is a challenge-response scheme, that prevents password sniffing on
untrusted connections. It is more secure than the <literal>md5</>
method, but might not be supported by older clients.
</para>
<para>
In <literal>md5</>, the client sends a hash of a random challenge,
generated by the server, and the password. It prevents password sniffing,
but is less secure than <literal>scram</>, and provides no protection
if an attacker manages to steal the password hash from the server.
<literal>md5</> cannot be used with the <xref
linkend="guc-db-user-namespace"> feature.
</para>
<para>