Subject: Re: [HACKERS] Changing references of password encryption to hashing

From: Bruce Momjian <[email-masked]>
Date: Tue, 21 Nov 2023 22:43:48 -0500

Is there any interest in fixing our documentation that says encrypted
when it means hashed?  Should I pursue this?

---------------------------------------------------------------------------

On Fri, Mar 10, 2017 at 11:16:02AM +0900, Michael Paquier wrote:
> Hi all,
> 
> As discussed here:
> https://www.postgresql.org/message-id/[email-masked]
> We are using in documentation and code comments "encryption" to define
> what actually is hashing, which is confusing.
> 
> Attached is a patch for HEAD to change the documentation to match hashing.
> 
> There are a couple of things I noticed on the way:
> 1) There is the user-visible PQencryptPassword in libpq, which
> actually hashes the password, and not encrypts it :)
> 2) There is as well pg_md5_encrypt() in the code, as well as there is
> pg_md5_hash(). Those may be better if renamed, at least I would think
> that pg_md5_encrypt should be pg_md5_password_hash, because a salt is
> used as well, and the routine is dedicated to work on passwords.
> Thoughts?
> 3) createuser also has --encrypt and --unencrypted, perhaps those
> should be renamed? Honestly I don't really think that this is worth a
> breakage and the option names match with the SQL commands.
> 
> I did not bother about those things in the attached, which works only
> documentation and comment changes.
> 
> An open item has been added on the wiki.
> 
> Thanks,
> -- 
> Michael

> diff --git a/contrib/pgcrypto/crypt-des.c b/contrib/pgcrypto/crypt-des.c
> index a4aa4966bf..1f65f286ea 100644
> --- a/contrib/pgcrypto/crypt-des.c
> +++ b/contrib/pgcrypto/crypt-des.c
> @@ -753,7 +753,7 @@ px_crypt_des(const char *key, const char *setting)
>  		output[0] = setting[0];
>  
>  		/*
> -		 * If the encrypted password that the salt was extracted from is only
> +		 * If the hashed password that the salt was extracted from is only
>  		 * 1 character long, the salt will be corrupted.  We need to ensure
>  		 * that the output string doesn't have an extra NUL in it!
>  		 */
> diff --git a/doc/src/sgml/catalogs.sgml b/doc/src/sgml/catalogs.sgml
> index 28cdabe6fe..abbd5dd19e 100644
> --- a/doc/src/sgml/catalogs.sgml
> +++ b/doc/src/sgml/catalogs.sgml
> @@ -1334,8 +1334,8 @@
>        <entry><structfield>rolpassword</structfield></entry>
>        <entry><type>text</type></entry>
>        <entry>
> -       Password (possibly encrypted); null if none. The format depends
> -       on the form of encryption used.
> +       Password (possibly hashed); null if none. The format depends
> +       on the form of hashing used.
>        </entry>
>       </row>
>  
> @@ -1350,19 +1350,20 @@
>    </table>
>  
>    <para>
> -   For an MD5 encrypted password, <structfield>rolpassword</structfield>
> +   For an MD5-hashed password, <structfield>rolpassword</structfield>
>     column will begin with the string <literal>md5</> followed by a
>     32-character hexadecimal MD5 hash. The MD5 hash will be of the user's
>     password concatenated to their user name. For example, if user
>     <literal>joe</> has password <literal>xyzzy</>, <productname>PostgreSQL</>
>     will store the md5 hash of <literal>xyzzyjoe</>.  If the password is
> -   encrypted with SCRAM-SHA-256, it consists of 5 fields separated by colons.
> +   hashed with SCRAM-SHA-256, it consists of 5 fields separated by colons.
>     The first field is the constant <literal>scram-sha-256</literal>, to
>     identify the password as a SCRAM-SHA-256 verifier. The second field is a
>     salt, Base64-encoded, and the third field is the number of iterations used
>     to generate the password.  The fourth field and fifth field are the stored
>     key and server key, respectively, in hexadecimal format. A password that
> -   does not follow either of those formats is assumed to be unencrypted.
> +   does not follow either of those formats is assumed to be in plain format,
> +   non-hashed.
>    </para>
>   </sect1>
>  
> @@ -10269,9 +10270,9 @@ SELECT * FROM pg_locks pl LEFT JOIN pg_prepared_xacts ppx
>        <entry><structfield>passwd</structfield></entry>
>        <entry><type>text</type></entry>
>        <entry></entry>
> -      <entry>Password (possibly encrypted); null if none.  See
> +      <entry>Password (possibly hashed); null if none.  See
>        <link linkend="catalog-pg-authid"><structname>pg_authid</structname></link>
> -      for details of how encrypted passwords are stored.</entry>
> +      for details of how hashed passwords are stored.</entry>
>       </row>
>  
>       <row>
> diff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/config.sgml
> index 69844e5b29..994ed6c1bd 100644
> --- a/doc/src/sgml/config.sgml
> +++ b/doc/src/sgml/config.sgml
> @@ -1190,11 +1190,11 @@ include_dir 'conf.d'
>          When a password is specified in <xref linkend="sql-createuser"> or
>          <xref linkend="sql-alterrole"> without writing either <literal>ENCRYPTED</>
>          or <literal>UNENCRYPTED</>, this parameter determines whether the
> -        password is to be encrypted. The default value is <literal>md5</>, which
> +        password is to be hashed. The default value is <literal>md5</>, which
>          stores the password as an MD5 hash. Setting this to <literal>plain</> stores
>          it in plaintext. <literal>on</> and <literal>off</> are also accepted, as
>          aliases for <literal>md5</> and <literal>plain</>, respectively.  Setting
> -        this parameter to <literal>scram</> will encrypt the password with
> +        this parameter to <literal>scram</> will hash the password with
>          SCRAM-SHA-256.
>         </para>       
>        </listitem>
> diff --git a/doc/src/sgml/passwordcheck.sgml b/doc/src/sgml/passwordcheck.sgml
> index 6e6e4ef435..8cf59946eb 100644
> --- a/doc/src/sgml/passwordcheck.sgml
> +++ b/doc/src/sgml/passwordcheck.sgml
> @@ -37,11 +37,11 @@
>  
>   <caution>
>    <para>
> -   To prevent unencrypted passwords from being sent across the network,
> +   To prevent non-hashed passwords from being sent across the network,
>     written to the server log or otherwise stolen by a database administrator,
>     <productname>PostgreSQL</productname> allows the user to supply
> -   pre-encrypted passwords. Many client programs make use of this
> -   functionality and encrypt the password before sending it to the server.
> +   pre-hashed passwords. Many client programs make use of this
> +   functionality and hash the password before sending it to the server.
>    </para>
>    <para>
>     This limits the usefulness of the <filename>passwordcheck</filename>
> @@ -54,7 +54,7 @@
>    </para>
>    <para>
>     Alternatively, you could modify <filename>passwordcheck</filename>
> -   to reject pre-encrypted passwords, but forcing users to set their
> +   to reject pre-hashed passwords, but forcing users to set their
>     passwords in clear text carries its own security risks.
>    </para>
>   </caution>
> diff --git a/doc/src/sgml/pgcrypto.sgml b/doc/src/sgml/pgcrypto.sgml
> index bf514aacf3..c4ce02c9dd 100644
> --- a/doc/src/sgml/pgcrypto.sgml
> +++ b/doc/src/sgml/pgcrypto.sgml
> @@ -109,7 +109,7 @@ hmac(data bytea, key text, type text) returns bytea
>     <listitem>
>      <para>
>       They use a random value, called the <firstterm>salt</>, so that users
> -     having the same password will have different encrypted passwords.
> +     having the same password will have different hashed passwords.
>       This is also an additional defense against reversing the algorithm.
>      </para>
>     </listitem>
> diff --git a/doc/src/sgml/protocol.sgml b/doc/src/sgml/protocol.sgml
> index 3d6e8eed43..52afe25090 100644
> --- a/doc/src/sgml/protocol.sgml
> +++ b/doc/src/sgml/protocol.sgml
> @@ -294,7 +294,7 @@
>        <listitem>
>         <para>
>          The frontend must now send a PasswordMessage containing the
> -        password (with user name) encrypted via MD5, then encrypted
> +        password (with user name) hashed via MD5, then hashed
>          again using the 4-byte random salt specified in the
>          AuthenticationMD5Password message.  If this is the correct
>          password, the server responds with an AuthenticationOk,
> @@ -2603,7 +2603,7 @@ AuthenticationMD5Password (B)
>  </term>
>  <listitem>
>  <para>
> -                Specifies that an MD5-encrypted password is required.
> +                Specifies that an MD5-hashed password is required.
>  </para>
>  </listitem>
>  </varlistentry>
> @@ -2613,7 +2613,7 @@ AuthenticationMD5Password (B)
>  </term>
>  <listitem>
>  <para>
> -                The salt to use when encrypting the password.
> +                The salt to use when hashing the password.
>  </para>
>  </listitem>
>  </varlistentry>
> @@ -4704,7 +4704,7 @@ PasswordMessage (F)
>  </term>
>  <listitem>
>  <para>
> -                The password (encrypted, if requested).
> +                The password (hashed, if requested).
>  </para>
>  </listitem>
>  </varlistentry>
> diff --git a/doc/src/sgml/ref/alter_role.sgml b/doc/src/sgml/ref/alter_role.sgml
> index da36ad9696..e242876967 100644
> --- a/doc/src/sgml/ref/alter_role.sgml
> +++ b/doc/src/sgml/ref/alter_role.sgml
> @@ -81,9 +81,9 @@ ALTER ROLE { <replaceable class="PARAMETER">role_specification</replaceable> | A
>     roles.
>     The current session user cannot be renamed.
>     (Connect as a different user if you need to do that.)
> -   Because <literal>MD5</>-encrypted passwords use the role name as
> +   Because <literal>MD5</>-hashed passwords use the role name as
>     cryptographic salt, renaming a role clears its password if the
> -   password is <literal>MD5</>-encrypted.
> +   password is <literal>MD5</>-hashed.
>    </para>
>  
>    <para>
> @@ -250,7 +250,7 @@ ALTER ROLE { <replaceable class="PARAMETER">role_specification</replaceable> | A
>    </para>
>  
>    <para>
> -   Caution must be exercised when specifying an unencrypted password
> +   Caution must be exercised when specifying a non-hashed password
>     with this command.  The password will be transmitted to the server
>     in cleartext, and it might also be logged in the client's command
>     history or the server log.  <xref linkend="app-psql">
> diff --git a/doc/src/sgml/ref/create_role.sgml b/doc/src/sgml/ref/create_role.sgml
> index 99d1c8336c..083fde6722 100644
> --- a/doc/src/sgml/ref/create_role.sgml
> +++ b/doc/src/sgml/ref/create_role.sgml
> @@ -228,14 +228,14 @@ CREATE ROLE <replaceable class="PARAMETER">name</replaceable> [ [ WITH ] <replac
>        <listitem>
>         <para>
>          These key words control whether the password is stored
> -        encrypted in the system catalogs.  (If neither is specified,
> +        hashed in the system catalogs.  (If neither is specified,
>          the default behavior is determined by the configuration
>          parameter <xref linkend="guc-password-encryption">.)  If the
> -        presented password string is already in MD5-encrypted or
> -        SCRAM-encrypted format, then it is stored encrypted as-is,
> +        presented password string is already in MD5-hashed or
> +        SCRAM-hashed format, then it is stored hased as-is,
>          regardless of whether <literal>ENCRYPTED</> or <literal>UNENCRYPTED</>
> -        is specified (since the system cannot decrypt the specified encrypted
> -        password string).  This allows reloading of encrypted passwords
> +        is specified (since the system cannot understand the specified hashed
> +        password string).  This allows reloading of hashed passwords
>          during dump/restore.
>         </para>
>  
> @@ -396,12 +396,12 @@ CREATE ROLE <replaceable class="PARAMETER">name</replaceable> [ [ WITH ] <replac
>    </para>
>  
>    <para>
> -   Caution must be exercised when specifying an unencrypted password
> +   Caution must be exercised when specifying a non-hashed password
>     with this command.  The password will be transmitted to the server
>     in cleartext, and it might also be logged in the client's command
>     history or the server log.  The command <xref
>     linkend="APP-CREATEUSER">, however, transmits
> -   the password encrypted.  Also, <xref linkend="app-psql">
> +   the password hash.  Also, <xref linkend="app-psql">
>     contains a command
>     <command>\password</command> that can be used to safely change the
>     password later.
> diff --git a/doc/src/sgml/ref/psql-ref.sgml b/doc/src/sgml/ref/psql-ref.sgml
> index 2a9c412020..0860b483a7 100644
> --- a/doc/src/sgml/ref/psql-ref.sgml
> +++ b/doc/src/sgml/ref/psql-ref.sgml
> @@ -2207,7 +2207,7 @@ lo_import 152801
>          <listitem>
>          <para>
>          Changes the password of the specified user (by default, the current
> -        user).  This command prompts for the new password, encrypts it, and
> +        user).  This command prompts for the new password, hashes it, and
>          sends it to the server as an <command>ALTER ROLE</> command.  This
>          makes sure that the new password does not appear in cleartext in the
>          command history, the server log, or elsewhere.
> diff --git a/doc/src/sgml/runtime.sgml b/doc/src/sgml/runtime.sgml
> index 5e3d783c6a..5f6b30f8df 100644
> --- a/doc/src/sgml/runtime.sgml
> +++ b/doc/src/sgml/runtime.sgml
> @@ -2024,15 +2024,15 @@ pg_dumpall -p 5432 | psql -d postgres -p 5433
>    <variablelist>
>  
>    <varlistentry>
> -   <term>Password Storage Encryption</term>
> +   <term>Password Storage Hashing</term>
>     <listitem>
>  
>      <para>
>       By default, database user passwords are stored as MD5 hashes, so
>       the administrator cannot determine the actual password assigned
> -     to the user. If MD5 encryption is used for client authentication,
> -     the unencrypted password is never even temporarily present on the
> -     server because the client MD5-encrypts it before being sent
> +     to the user. If MD5 hashing is used for client authentication,
> +     the non-hashed password is never even temporarily present on the
> +     server because the client MD5-hashes it before being sent
>       across the network.
>      </para>
>     </listitem>
> @@ -2088,18 +2088,18 @@ pg_dumpall -p 5432 | psql -d postgres -p 5433
>    </varlistentry>
>  
>    <varlistentry>
> -   <term>Encrypting Passwords Across A Network</term>
> +   <term>Hashing Passwords Across A Network</term>
>  
>     <listitem>
>       <para>
> -      The <literal>MD5</> authentication method double-encrypts the
> +      The <literal>MD5</> authentication method double-hashes the
>        password on the client before sending it to the server. It first
> -      MD5-encrypts it based on the user name, and then encrypts it
> +      MD5-hashes it based on the user name, and then hashes it
>        based on a random salt sent by the server when the database
> -      connection was made. It is this double-encrypted value that is
> -      sent over the network to the server. Double-encryption not only
> +      connection was made. It is this double-hashed value that is
> +      sent over the network to the server. Double-hash not only
>        prevents the password from being discovered, it also prevents
> -      another connection from using the same encrypted password to
> +      another connection from using the same hashed password to
>        connect to the database server at a later time.
>       </para>
>      </listitem>
> diff --git a/src/backend/commands/user.c b/src/backend/commands/user.c
> index 14b9779144..e4ad531fa6 100644
> --- a/src/backend/commands/user.c
> +++ b/src/backend/commands/user.c
> @@ -397,7 +397,7 @@ CreateRole(ParseState *pstate, CreateRoleStmt *stmt)
>  
>  	if (password)
>  	{
> -		/* Encrypt the password to the requested format. */
> +		/* Hash the password to the requested format. */
>  		char	   *shadow_pass;
>  
>  		shadow_pass = encrypt_password(password_type, stmt->role, password);
> @@ -806,7 +806,7 @@ AlterRole(AlterRoleStmt *stmt)
>  	/* password */
>  	if (password)
>  	{
> -		/* Encrypt the password to the requested format. */
> +		/* Hash the password to the requested format. */
>  		char	   *shadow_pass;
>  
>  		shadow_pass = encrypt_password(password_type, rolename, password);
> diff --git a/src/backend/libpq/auth-scram.c b/src/backend/libpq/auth-scram.c
> index 9f78e57aae..8e7344d95a 100644
> --- a/src/backend/libpq/auth-scram.c
> +++ b/src/backend/libpq/auth-scram.c
> @@ -147,7 +147,7 @@ pg_be_scram_init(const char *username, const char *shadow_pass, bool doomed)
>  	/*
>  	 * Perform sanity checks on the provided password after catalog lookup.
>  	 * The authentication is bound to fail if the lookup itself failed or if
> -	 * the password stored is MD5-encrypted.  Authentication is possible for
> +	 * the password stored is MD5-hashed.  Authentication is possible for
>  	 * users with a valid plain password though.
>  	 */
>  
> diff --git a/src/backend/libpq/auth.c b/src/backend/libpq/auth.c
> index ebf10bbbae..61217f0fa4 100644
> --- a/src/backend/libpq/auth.c
> +++ b/src/backend/libpq/auth.c
> @@ -2723,7 +2723,7 @@ CheckRADIUSAuth(Port *port)
>  		if (!pg_md5_binary(cryptvector, strlen(port->hba->radiussecret) + RADIUS_VECTOR_LENGTH, encryptedpassword + i))
>  		{
>  			ereport(LOG,
> -					(errmsg("could not perform MD5 encryption of password")));
> +					(errmsg("could not perform MD5 hash of password")));
>  			pfree(cryptvector);
>  			return STATUS_ERROR;
>  		}
> @@ -2924,7 +2924,7 @@ CheckRADIUSAuth(Port *port)
>  						   encryptedpassword))
>  		{
>  			ereport(LOG,
> -			(errmsg("could not perform MD5 encryption of received packet")));
> +			(errmsg("could not perform MD5 hash of received packet")));
>  			pfree(cryptvector);
>  			continue;
>  		}
> diff --git a/src/backend/libpq/crypt.c b/src/backend/libpq/crypt.c
> index bd3e936d38..2cc3344f6e 100644
> --- a/src/backend/libpq/crypt.c
> +++ b/src/backend/libpq/crypt.c
> @@ -1,7 +1,7 @@
>  /*-------------------------------------------------------------------------
>   *
>   * crypt.c
> - *	  Functions for dealing with encrypted passwords stored in
> + *	  Functions for dealing with hashed passwords stored in
>   *	  pg_authid.rolpassword.
>   *
>   * Portions Copyright (c) 1996-2017, PostgreSQL Global Development Group
> @@ -150,7 +150,7 @@ encrypt_password(PasswordType target_type, const char *role,
>  
>  					if (!pg_md5_encrypt(password, role, strlen(role),
>  										encrypted_password))
> -						elog(ERROR, "password encryption failed");
> +						elog(ERROR, "password hashing failed");
>  					return encrypted_password;
>  
>  				case PASSWORD_TYPE_SCRAM:
> @@ -184,7 +184,7 @@ encrypt_password(PasswordType target_type, const char *role,
>  	 * This shouldn't happen, because the above switch statements should
>  	 * handle every combination of source and target password types.
>  	 */
> -	elog(ERROR, "cannot encrypt password to requested type");
> +	elog(ERROR, "cannot hash password to requested type");
>  	return NULL;				/* keep compiler quiet */
>  }
>  
> @@ -221,7 +221,7 @@ md5_crypt_verify(const char *role, const char *shadow_pass,
>  	switch (get_password_type(shadow_pass))
>  	{
>  		case PASSWORD_TYPE_MD5:
> -			/* stored password already encrypted, only do salt */
> +			/* stored password already hashed, only do salt */
>  			if (!pg_md5_encrypt(shadow_pass + strlen("md5"),
>  								md5_salt, md5_salt_len,
>  								crypt_pwd))
> @@ -231,7 +231,7 @@ md5_crypt_verify(const char *role, const char *shadow_pass,
>  			break;
>  
>  		case PASSWORD_TYPE_PLAINTEXT:
> -			/* stored password is plain, double-encrypt */
> +			/* stored password is plain, double-hash */
>  			if (!pg_md5_encrypt(shadow_pass,
>  								role,
>  								strlen(role),
> diff --git a/src/backend/libpq/pg_hba.conf.sample b/src/backend/libpq/pg_hba.conf.sample
> index 6b1778a721..6b4ab71cb6 100644
> --- a/src/backend/libpq/pg_hba.conf.sample
> +++ b/src/backend/libpq/pg_hba.conf.sample
> @@ -45,7 +45,7 @@
>  # METHOD can be "trust", "reject", "md5", "password", "scram", "gss",
>  # "sspi", "ident", "peer", "pam", "ldap", "radius" or "cert".  Note that
>  # "password" sends passwords in clear text; "md5" or "scram" are preferred
> -# since they send encrypted passwords.
> +# since they send hashed passwords.
>  #
>  # OPTIONS are a set of options for the authentication in the format
>  # NAME=VALUE.  The available options depend on the different
> diff --git a/src/bin/psql/command.c b/src/bin/psql/command.c
> index 07efc27a69..0dbe7017a8 100644
> --- a/src/bin/psql/command.c
> +++ b/src/bin/psql/command.c
> @@ -1138,7 +1138,7 @@ exec_command(const char *cmd,
>  
>  			if (!encrypted_password)
>  			{
> -				psql_error("Password encryption failed.\n");
> +				psql_error("Password hashing failed.\n");
>  				success = false;
>  			}
>  			else
> diff --git a/src/bin/scripts/createuser.c b/src/bin/scripts/createuser.c
> index 3d74797a8f..b398f6a1e1 100644
> --- a/src/bin/scripts/createuser.c
> +++ b/src/bin/scripts/createuser.c
> @@ -278,7 +278,7 @@ main(int argc, char *argv[])
>  												   newuser);
>  			if (!encrypted_password)
>  			{
> -				fprintf(stderr, _("Password encryption failed.\n"));
> +				fprintf(stderr, _("Password hashing failed.\n"));
>  				exit(1);
>  			}
>  			appendStringLiteralConn(&sql, encrypted_password, conn);
> @@ -358,14 +358,14 @@ help(const char *progname)
>  	printf(_("  -d, --createdb            role can create new databases\n"));
>  	printf(_("  -D, --no-createdb         role cannot create databases (default)\n"));
>  	printf(_("  -e, --echo                show the commands being sent to the server\n"));
> -	printf(_("  -E, --encrypted           encrypt stored password\n"));
> +	printf(_("  -E, --encrypted           hash stored password\n"));
>  	printf(_("  -g, --role=ROLE           new role will be a member of this role\n"));
>  	printf(_("  -i, --inherit             role inherits privileges of roles it is a\n"
>  			 "                            member of (default)\n"));
>  	printf(_("  -I, --no-inherit          role does not inherit privileges\n"));
>  	printf(_("  -l, --login               role can login (default)\n"));
>  	printf(_("  -L, --no-login            role cannot login\n"));
> -	printf(_("  -N, --unencrypted         do not encrypt stored password\n"));
> +	printf(_("  -N, --unencrypted         do not hash stored password\n"));
>  	printf(_("  -P, --pwprompt            assign a password to new role\n"));
>  	printf(_("  -r, --createrole          role can create new roles\n"));
>  	printf(_("  -R, --no-createrole       role cannot create roles (default)\n"));
> diff --git a/src/common/scram-common.c b/src/common/scram-common.c
> index e44f38f652..712d51900d 100644
> --- a/src/common/scram-common.c
> +++ b/src/common/scram-common.c
> @@ -148,7 +148,7 @@ scram_H(const uint8 *input, int len, uint8 *result)
>  }
>  
>  /*
> - * Encrypt password for SCRAM authentication. This basically applies the
> + * Hash password for SCRAM authentication. This basically applies the
>   * normalization of the password and a hash calculation using the salt
>   * value given by caller.
>   */
> diff --git a/src/include/common/md5.h b/src/include/common/md5.h
> index ccaaeddbf4..37e2432021 100644
> --- a/src/include/common/md5.h
> +++ b/src/include/common/md5.h
> @@ -4,7 +4,7 @@
>   *	  Interface to libpq/md5.c
>   *
>   * These definitions are needed by both frontend and backend code to work
> - * with MD5-encrypted passwords.
> + * with MD5-hashed passwords.
>   *
>   * Portions Copyright (c) 1996-2017, PostgreSQL Global Development Group
>   * Portions Copyright (c) 1994, Regents of the University of California
> diff --git a/src/interfaces/libpq/fe-auth.c b/src/interfaces/libpq/fe-auth.c
> index 5fe7e565a0..385c0472bf 100644
> --- a/src/interfaces/libpq/fe-auth.c
> +++ b/src/interfaces/libpq/fe-auth.c
> @@ -583,7 +583,7 @@ pg_password_sendauth(PGconn *conn, const char *password, AuthRequest areq)
>  	char	   *crypt_pwd = NULL;
>  	const char *pwd_to_send;
>  
> -	/* Encrypt the password if needed. */
> +	/* Hash the password if needed. */
>  
>  	switch (areq)
>  	{
> @@ -909,14 +909,14 @@ pg_fe_getauthname(PQExpBuffer errorMessage)
>  
>  
>  /*
> - * PQencryptPassword -- exported routine to encrypt a password
> + * PQencryptPassword -- exported routine to hash a password
>   *
>   * This is intended to be used by client applications that wish to send
>   * commands like ALTER USER joe PASSWORD 'pwd'.  The password need not
> - * be sent in cleartext if it is encrypted on the client side.  This is
> + * be sent in cleartext if it is hashed on the client side.  This is
>   * good because it ensures the cleartext password won't end up in logs,
>   * pg_stat displays, etc.  We export the function so that clients won't
> - * be dependent on low-level details like whether the encryption is MD5
> + * be dependent on low-level details like whether the hashing is MD5
>   * or something else.
>   *
>   * Arguments are the cleartext password, and the SQL name of the user it
> diff --git a/src/test/regress/expected/password.out b/src/test/regress/expected/password.out
> index c503e43abe..7fe09e6f00 100644
> --- a/src/test/regress/expected/password.out
> +++ b/src/test/regress/expected/password.out
> @@ -55,14 +55,14 @@ SELECT rolname, rolpassword
>  
>  ALTER ROLE regress_passwd3_new RENAME TO regress_passwd3;
>  -- ENCRYPTED and UNENCRYPTED passwords
> -ALTER ROLE regress_passwd1 UNENCRYPTED PASSWORD 'foo'; -- unencrypted
> -ALTER ROLE regress_passwd2 UNENCRYPTED PASSWORD 'md5dfa155cadd5f4ad57860162f3fab9cdb'; -- encrypted with MD5
> +ALTER ROLE regress_passwd1 UNENCRYPTED PASSWORD 'foo'; -- non-hashed
> +ALTER ROLE regress_passwd2 UNENCRYPTED PASSWORD 'md5dfa155cadd5f4ad57860162f3fab9cdb'; -- hashed with MD5
>  SET password_encryption = 'md5';
> -ALTER ROLE regress_passwd3 ENCRYPTED PASSWORD 'foo'; -- encrypted with MD5
> +ALTER ROLE regress_passwd3 ENCRYPTED PASSWORD 'foo'; -- hashed with MD5
>  ALTER ROLE regress_passwd4 ENCRYPTED PASSWORD 'scram-sha-256:VLK4RMaQLCvNtQ==:4096:3ded2376f7aafa93b1bdbd71bcc18b7d6ee50ed018029cc583d152ef3fc7d430:a6dd36dfc94c181956a6ae95f05e01b1864f0a22a2657d1de4ba84d2a24dc438'; -- client-supplied SCRAM verifier, use as it is
>  SET password_encryption = 'scram';
>  ALTER ROLE  regress_passwd5 ENCRYPTED PASSWORD 'foo'; -- create SCRAM verifier
> -CREATE ROLE regress_passwd6 ENCRYPTED PASSWORD 'md53725413363ab045e20521bf36b8d8d7f'; -- encrypted with MD5, use as it is
> +CREATE ROLE regress_passwd6 ENCRYPTED PASSWORD 'md53725413363ab045e20521bf36b8d8d7f'; -- hashed with MD5, use as it is
>  SELECT rolname, regexp_replace(rolpassword, '(scram-sha-256):([a-zA-Z0-9+/]+==):(\d+):(\w+):(\w+)', '\1:<salt>:\3:<storedkey>:<serverkey>') as rolpassword_masked
>      FROM pg_authid
>      WHERE rolname LIKE 'regress_passwd%'
> diff --git a/src/test/regress/sql/password.sql b/src/test/regress/sql/password.sql
> index f4b3a9ac3a..aa88d5ef82 100644
> --- a/src/test/regress/sql/password.sql
> +++ b/src/test/regress/sql/password.sql
> @@ -43,16 +43,16 @@ SELECT rolname, rolpassword
>  ALTER ROLE regress_passwd3_new RENAME TO regress_passwd3;
>  
>  -- ENCRYPTED and UNENCRYPTED passwords
> -ALTER ROLE regress_passwd1 UNENCRYPTED PASSWORD 'foo'; -- unencrypted
> -ALTER ROLE regress_passwd2 UNENCRYPTED PASSWORD 'md5dfa155cadd5f4ad57860162f3fab9cdb'; -- encrypted with MD5
> +ALTER ROLE regress_passwd1 UNENCRYPTED PASSWORD 'foo'; -- non-hashed
> +ALTER ROLE regress_passwd2 UNENCRYPTED PASSWORD 'md5dfa155cadd5f4ad57860162f3fab9cdb'; -- hashed with MD5
>  SET password_encryption = 'md5';
> -ALTER ROLE regress_passwd3 ENCRYPTED PASSWORD 'foo'; -- encrypted with MD5
> +ALTER ROLE regress_passwd3 ENCRYPTED PASSWORD 'foo'; -- hashed with MD5
>  
>  ALTER ROLE regress_passwd4 ENCRYPTED PASSWORD 'scram-sha-256:VLK4RMaQLCvNtQ==:4096:3ded2376f7aafa93b1bdbd71bcc18b7d6ee50ed018029cc583d152ef3fc7d430:a6dd36dfc94c181956a6ae95f05e01b1864f0a22a2657d1de4ba84d2a24dc438'; -- client-supplied SCRAM verifier, use as it is
>  
>  SET password_encryption = 'scram';
>  ALTER ROLE  regress_passwd5 ENCRYPTED PASSWORD 'foo'; -- create SCRAM verifier
> -CREATE ROLE regress_passwd6 ENCRYPTED PASSWORD 'md53725413363ab045e20521bf36b8d8d7f'; -- encrypted with MD5, use as it is
> +CREATE ROLE regress_passwd6 ENCRYPTED PASSWORD 'md53725413363ab045e20521bf36b8d8d7f'; -- hashed with MD5, use as it is
>  
>  SELECT rolname, regexp_replace(rolpassword, '(scram-sha-256):([a-zA-Z0-9+/]+==):(\d+):(\w+):(\w+)', '\1:<salt>:\3:<storedkey>:<serverkey>') as rolpassword_masked
>      FROM pg_authid

> 
> -- 
> Sent via pgsql-hackers mailing list ([email-masked])
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers

-- 
  Bruce Momjian  <[email-masked]>        https://momjian.us
  EDB                                      https://enterprisedb.com

  Only you can decide what is important to you.

---

From: Stephen Frost <[email-masked]>
Date: Tue, 28 Nov 2023 09:55:31 -0500

Greetings,

> when it means hashed?  Should I pursue this?

I do think we should use the correct terminology in our documentation
and would support your working on improving things in this area.

I do wonder if perhaps we would be better off by having someone spend
time on removing terribly insecure authentication methods like md5 and
ldap though ...

Thanks,

Stephen

---

From: Robert Haas <[email-masked]>
Date: Tue, 28 Nov 2023 10:01:57 -0500

> and would support your working on improving things in this area.

+1.

> time on removing terribly insecure authentication methods like md5 and

Wait, what's insecure about LDAP?

I think we should eventually remove MD5, but I think there's no rush.
People who care about security will have already switched, and people
who don't care about security are not required to start caring.
Eventually the maintenance burden will become large enough that it
makes sense to phase it out for that reason, but I haven't seen any
evidence that we're anywhere close to that point.

-- 
Robert Haas
EDB: http://www.enterprisedb.com

---

From: Stephen Frost <[email-masked]>
Date: Tue, 28 Nov 2023 10:16:41 -0500

Greetings,

> Wait, what's insecure about LDAP?

We pass a completely cleartext password to the server from the client.
Yes, we might encrypt it on the way with TLS, but even SSH realized how
terrible that is long, long ago and strongly discourages it these days.

The problem with ldap as an auth method is that a single compromised PG
server in an AD/ldap environment can collect up those username+password
credentials and gain access to those users *domain* level access.  The
CFO logging into a PG server with LDAP auth is giving up their complete
access credentials to the entire AD domain.  That's terrible.

> I think we should eventually remove MD5, but I think there's no rush.

I disagree- it's a known pass-the-hash vulnerability and frankly every
release we do with it still existing is deserving of an immediate CVE
(I've been asked off-list why we don't do this, in fact).

> who don't care about security are not required to start caring.

I wish it were this simple.  It's just not though.

> evidence that we're anywhere close to that point.

This seems to invite the idea that what people who care about this need
to do is make it painful for us to continue to keep it around, which I
really don't think is best for anyone.  We know it's bad, we know it is
broken, we need to remove it, not pretend like it's not broken or not
bad.

Thanks,

Stephen