1
0
mirror of https://github.com/postgres/postgres.git synced 2025-11-07 19:06:32 +03:00

Rename "scram" to "scram-sha-256" in pg_hba.conf and password_encryption.

Per discussion, plain "scram" is confusing because we actually implement
SCRAM-SHA-256 rather than the original SCRAM that uses SHA-1 as the hash
algorithm. If we add support for SCRAM-SHA-512 or some other mechanism in
the SCRAM family in the future, that would become even more confusing.

Most of the internal files and functions still use just "scram" as a
shorthand for SCRMA-SHA-256, but I did change PASSWORD_TYPE_SCRAM to
PASSWORD_TYPE_SCRAM_SHA_256, as that could potentially be used by 3rd
party extensions that hook into the password-check hook.

Michael Paquier did this in an earlier version of the SCRAM patch set
already, but I didn't include that in the version that was committed.

Discussion: https://www.postgresql.org/message-id/fde71ff1-5858-90c8-99a9-1c2427e7bafb@iki.fi
This commit is contained in:
Heikki Linnakangas
2017-04-18 14:50:50 +03:00
parent 123aaffb5b
commit c727f120ff
15 changed files with 60 additions and 59 deletions

View File

@@ -50,7 +50,7 @@ static char *recv_password_packet(Port *port);
/*----------------------------------------------------------------
* Password-based authentication methods (password, md5, and scram)
* Password-based authentication methods (password, md5, and scram-sha-256)
*----------------------------------------------------------------
*/
static int CheckPasswordAuth(Port *port, char **logdetail);
@@ -757,10 +757,10 @@ CheckPWChallengeAuth(Port *port, char **logdetail)
* If the user does not exist, or has no password, we still go through the
* motions of authentication, to avoid revealing to the client that the
* user didn't exist. If 'md5' is allowed, we choose whether to use 'md5'
* or 'scram' authentication based on current password_encryption setting.
* The idea is that most genuine users probably have a password of that
* type, if we pretend that this user had a password of that type, too, it
* "blends in" best.
* or 'scram-sha-256' authentication based on current password_encryption
* setting. The idea is that most genuine users probably have a password
* of that type, if we pretend that this user had a password of that type,
* too, it "blends in" best.
*
* If the user had a password, but it was expired, we'll use the details
* of the expired password for the authentication, but report it as
@@ -773,9 +773,9 @@ CheckPWChallengeAuth(Port *port, char **logdetail)
/*
* If 'md5' authentication is allowed, decide whether to perform 'md5' or
* 'scram' authentication based on the type of password the user has. If
* it's an MD5 hash, we must do MD5 authentication, and if it's a SCRAM
* verifier, we must do SCRAM authentication. If it's stored in
* 'scram-sha-256' authentication based on the type of password the user
* has. If it's an MD5 hash, we must do MD5 authentication, and if it's
* a SCRAM verifier, we must do SCRAM authentication. If it's stored in
* plaintext, we could do either one, so we opt for the more secure
* mechanism, SCRAM.
*