public inbox for [email protected]
help / color / mirror / Atom feedChanging references of password encryption to hashing
9+ messages / 7 participants
[nested] [flat]
* Changing references of password encryption to hashing
@ 2017-03-10 02:16 Michael Paquier <[email protected]>
2017-03-11 22:51 ` Re: Changing references of password encryption to hashing Joe Conway <[email protected]>
0 siblings, 1 reply; 9+ messages in thread
From: Michael Paquier @ 2017-03-10 02:16 UTC (permalink / raw)
To: pgsql-hackers
Hi all,
As discussed here:
https://www.postgresql.org/message-id/[email protected]
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
--
Sent via pgsql-hackers mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Attachments:
[application/octet-stream] hashed-passwords-doc.patch (25.5K, ../../CAB7nPqR82_57C8O1+z-bUChhHpdjMec_omLfKwYdjAFjjcrBWg@mail.gmail.com/2-hashed-passwords-doc.patch)
download | inline diff:
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
^ permalink raw reply [nested|flat] 9+ messages in thread
* Re: Changing references of password encryption to hashing
2017-03-10 02:16 Changing references of password encryption to hashing Michael Paquier <[email protected]>
@ 2017-03-11 22:51 ` Joe Conway <[email protected]>
2017-03-13 07:11 ` Re: Changing references of password encryption to hashing Michael Paquier <[email protected]>
2017-03-13 08:48 ` Re: Changing references of password encryption to hashing Craig Ringer <[email protected]>
0 siblings, 2 replies; 9+ messages in thread
From: Joe Conway @ 2017-03-11 22:51 UTC (permalink / raw)
To: Michael Paquier <[email protected]>; pgsql-hackers
On 03/09/2017 06:16 PM, Michael Paquier wrote:
> As discussed here:
> https://www.postgresql.org/message-id/[email protected]
> 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.
My opinion is that the user visible aspects of this should be deprecated
and correct syntax provided. But perhaps that is overkill.
8<------------
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>
8<------------
I think here, instead of "in plain format, non-hashed" it is ok to just
say "cleartext" or maybe "plaintext". Whichever is picked, it should be
used consistently.
8<------------
<caution>
<para>
- To prevent unencrypted passwords from being sent across the network,
+ To prevent non-hashed passwords from being sent across the network,
8<------------
same here "non-hashed" ==> "cleartext"
8<------------
<para>
- Caution must be exercised when specifying an unencrypted password
+ Caution must be exercised when specifying a non-hashed password
8<------------
and here
...etc...
Joe
--
Crunchy Data - http://crunchydata.com
PostgreSQL Support for Secure Enterprises
Consulting, Training, & Open Source Development
Attachments:
[application/pgp-signature] signature.asc (819B, ../../[email protected]/2-signature.asc)
download
^ permalink raw reply [nested|flat] 9+ messages in thread
* Re: Changing references of password encryption to hashing
2017-03-10 02:16 Changing references of password encryption to hashing Michael Paquier <[email protected]>
2017-03-11 22:51 ` Re: Changing references of password encryption to hashing Joe Conway <[email protected]>
@ 2017-03-13 07:11 ` Michael Paquier <[email protected]>
1 sibling, 0 replies; 9+ messages in thread
From: Michael Paquier @ 2017-03-13 07:11 UTC (permalink / raw)
To: Joe Conway <[email protected]>; +Cc: pgsql-hackers
On Sun, Mar 12, 2017 at 7:51 AM, Joe Conway <[email protected]> wrote:
> On 03/09/2017 06:16 PM, Michael Paquier wrote:
>> As discussed here:
>> https://www.postgresql.org/message-id/[email protected]
>> 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.
>
> My opinion is that the user visible aspects of this should be deprecated
> and correct syntax provided. But perhaps that is overkill.
Are ENCRYPTED and UNENCRYPTED keywords part of the SQL specification?
If yes, we had better not do 3) then. 1) and 2) would make future
back-patching harder, so I am not going to push much as I am expecting
some growling on the matter, and a doc-only patch is a step in the
good direction anyway. Extra opinions are welcome.
> 8<------------
> 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>
> 8<------------
> I think here, instead of "in plain format, non-hashed" it is ok to just
> say "cleartext" or maybe "plaintext". Whichever is picked, it should be
> used consistently.
OK, thanks. cleartext is present in the docs already, so I have gone
for this term. Updated patch attached.
--
Michael
--
Sent via pgsql-hackers mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Attachments:
[application/octet-stream] hashed-passwords-doc-v2.patch (25.4K, ../../CAB7nPqTbkEM1ALjcVif+ouJZF60+wsrwNDgxa6uwLeYJV_UbTA@mail.gmail.com/2-hashed-passwords-doc-v2.patch)
download | inline diff:
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 2c2da2ad8a..69baa41d26 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,19 @@
</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 cleartext.
</para>
</sect1>
@@ -10272,9 +10272,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..5964c6b3ad 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 cleartext 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..5b67882398 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 cleartext 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..27895e8298 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 cleartext 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 01153f9a37..0915a42736 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 cleartext 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 9f0ae15b00..5022738b4f 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:
@@ -186,7 +186,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 */
}
@@ -223,7 +223,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))
@@ -233,7 +233,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 4f4a0aa9bd..7c272a1c5d 100644
--- a/src/bin/psql/command.c
+++ b/src/bin/psql/command.c
@@ -1139,7 +1139,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..7cc143554f 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'; -- cleartext
+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..e7a1ddf42a 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'; -- cleartext
+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
^ permalink raw reply [nested|flat] 9+ messages in thread
* Re: Changing references of password encryption to hashing
2017-03-10 02:16 Changing references of password encryption to hashing Michael Paquier <[email protected]>
2017-03-11 22:51 ` Re: Changing references of password encryption to hashing Joe Conway <[email protected]>
@ 2017-03-13 08:48 ` Craig Ringer <[email protected]>
2017-03-16 03:19 ` Re: Changing references of password encryption to hashing Bruce Momjian <[email protected]>
2017-03-16 13:19 ` Re: Changing references of password encryption to hashing Robert Haas <[email protected]>
1 sibling, 2 replies; 9+ messages in thread
From: Craig Ringer @ 2017-03-13 08:48 UTC (permalink / raw)
To: Joe Conway <[email protected]>; +Cc: Michael Paquier <[email protected]>; pgsql-hackers
On 12 March 2017 at 06:51, Joe Conway <[email protected]> wrote:
> My opinion is that the user visible aspects of this should be deprecated
> and correct syntax provided. But perhaps that is overkill.
FWIW, in my experience, pretty much nobody understands the pretty
tangled behaviour of "WITH [ENCRYPTED] PASSWORD", you have to
understand the fact table of:
* ENCRYPTED, UNENCRYPTED or neither set
* password_encryption GUC on or off
* password begins / doesn't begin with fixed string 'md5'
to fully know what will happen.
Then of course, you have to understand how all this interacts with
pg_hba.conf's 'password' and 'md5' options.
It's a right mess. Since our catalogs don't keep track of the hash
separately to the password text and use prefixes instead, and since we
need compatibility for dumps, it's hard to do a great deal about
though.
I'm not convinced that a keyword change will do much good, the whole
thing really needs a reassessment to make sure that it's clearer to
users/admins and has fewer moving parts.
So I'm in favour of fixing the docs but I'm not keen on changing the
SQL syntax in a way that just kind of papers over part of the
problems.
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
^ permalink raw reply [nested|flat] 9+ messages in thread
* Re: Changing references of password encryption to hashing
2017-03-10 02:16 Changing references of password encryption to hashing Michael Paquier <[email protected]>
2017-03-11 22:51 ` Re: Changing references of password encryption to hashing Joe Conway <[email protected]>
2017-03-13 08:48 ` Re: Changing references of password encryption to hashing Craig Ringer <[email protected]>
@ 2017-03-16 03:19 ` Bruce Momjian <[email protected]>
1 sibling, 0 replies; 9+ messages in thread
From: Bruce Momjian @ 2017-03-16 03:19 UTC (permalink / raw)
To: Craig Ringer <[email protected]>; +Cc: Joe Conway <[email protected]>; Michael Paquier <[email protected]>; pgsql-hackers
On Mon, Mar 13, 2017 at 04:48:21PM +0800, Craig Ringer wrote:
> On 12 March 2017 at 06:51, Joe Conway <[email protected]> wrote:
>
> > My opinion is that the user visible aspects of this should be deprecated
> > and correct syntax provided. But perhaps that is overkill.
>
> FWIW, in my experience, pretty much nobody understands the pretty
> tangled behaviour of "WITH [ENCRYPTED] PASSWORD", you have to
> understand the fact table of:
>
> * ENCRYPTED, UNENCRYPTED or neither set
> * password_encryption GUC on or off
> * password begins / doesn't begin with fixed string 'md5'
>
> to fully know what will happen.
>
> Then of course, you have to understand how all this interacts with
> pg_hba.conf's 'password' and 'md5' options.
>
> It's a right mess. Since our catalogs don't keep track of the hash
> separately to the password text and use prefixes instead, and since we
> need compatibility for dumps, it's hard to do a great deal about
> though.
With SCRAM coming in PG 10, is there anything we can do to clean this up
for PG 10?
--
Bruce Momjian <[email protected]> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +
--
Sent via pgsql-hackers mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
^ permalink raw reply [nested|flat] 9+ messages in thread
* Re: Changing references of password encryption to hashing
2017-03-10 02:16 Changing references of password encryption to hashing Michael Paquier <[email protected]>
2017-03-11 22:51 ` Re: Changing references of password encryption to hashing Joe Conway <[email protected]>
2017-03-13 08:48 ` Re: Changing references of password encryption to hashing Craig Ringer <[email protected]>
@ 2017-03-16 13:19 ` Robert Haas <[email protected]>
2017-03-16 14:27 ` Re: Changing references of password encryption to hashing Joe Conway <[email protected]>
1 sibling, 1 reply; 9+ messages in thread
From: Robert Haas @ 2017-03-16 13:19 UTC (permalink / raw)
To: Craig Ringer <[email protected]>; +Cc: Joe Conway <[email protected]>; Michael Paquier <[email protected]>; pgsql-hackers
On Mon, Mar 13, 2017 at 4:48 AM, Craig Ringer <[email protected]> wrote:
> So I'm in favour of fixing the docs but I'm not keen on changing the
> SQL syntax in a way that just kind of papers over part of the
> problems.
I agree. I think that trying to design new SQL syntax at this point
is unlikely to be a good idea - we're just about out of time here, and
some people who might care about this are busy on other things, and
the deadline for patches that do new things has long since passed.
But I like the idea of trying to improve the documentation.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
^ permalink raw reply [nested|flat] 9+ messages in thread
* Re: Changing references of password encryption to hashing
2017-03-10 02:16 Changing references of password encryption to hashing Michael Paquier <[email protected]>
2017-03-11 22:51 ` Re: Changing references of password encryption to hashing Joe Conway <[email protected]>
2017-03-13 08:48 ` Re: Changing references of password encryption to hashing Craig Ringer <[email protected]>
2017-03-16 13:19 ` Re: Changing references of password encryption to hashing Robert Haas <[email protected]>
@ 2017-03-16 14:27 ` Joe Conway <[email protected]>
2017-03-16 14:30 ` Re: Changing references of password encryption to hashing Stephen Frost <[email protected]>
2017-04-06 05:31 ` Re: Changing references of password encryption to hashing Noah Misch <[email protected]>
0 siblings, 2 replies; 9+ messages in thread
From: Joe Conway @ 2017-03-16 14:27 UTC (permalink / raw)
To: Robert Haas <[email protected]>; Craig Ringer <[email protected]>; +Cc: Michael Paquier <[email protected]>; pgsql-hackers
On 03/16/2017 06:19 AM, Robert Haas wrote:
> On Mon, Mar 13, 2017 at 4:48 AM, Craig Ringer <[email protected]> wrote:
>> So I'm in favour of fixing the docs but I'm not keen on changing the
>> SQL syntax in a way that just kind of papers over part of the
>> problems.
>
> I agree. I think that trying to design new SQL syntax at this point
> is unlikely to be a good idea - we're just about out of time here, and
> some people who might care about this are busy on other things, and
> the deadline for patches that do new things has long since passed.
> But I like the idea of trying to improve the documentation.
Agreed. I think the documentation fixes definitely should be done, but
understand that the grammar is a longer term issue with backward
compatibility implications. Acknowledging the problem is the first step ;-)
Joe
--
Crunchy Data - http://crunchydata.com
PostgreSQL Support for Secure Enterprises
Consulting, Training, & Open Source Development
Attachments:
[application/pgp-signature] signature.asc (819B, ../../[email protected]/2-signature.asc)
download
^ permalink raw reply [nested|flat] 9+ messages in thread
* Re: Changing references of password encryption to hashing
2017-03-10 02:16 Changing references of password encryption to hashing Michael Paquier <[email protected]>
2017-03-11 22:51 ` Re: Changing references of password encryption to hashing Joe Conway <[email protected]>
2017-03-13 08:48 ` Re: Changing references of password encryption to hashing Craig Ringer <[email protected]>
2017-03-16 13:19 ` Re: Changing references of password encryption to hashing Robert Haas <[email protected]>
2017-03-16 14:27 ` Re: Changing references of password encryption to hashing Joe Conway <[email protected]>
@ 2017-03-16 14:30 ` Stephen Frost <[email protected]>
1 sibling, 0 replies; 9+ messages in thread
From: Stephen Frost @ 2017-03-16 14:30 UTC (permalink / raw)
To: Joe Conway <[email protected]>; +Cc: Robert Haas <[email protected]>; Craig Ringer <[email protected]>; Michael Paquier <[email protected]>; pgsql-hackers
* Joe Conway ([email protected]) wrote:
> On 03/16/2017 06:19 AM, Robert Haas wrote:
> > On Mon, Mar 13, 2017 at 4:48 AM, Craig Ringer <[email protected]> wrote:
> >> So I'm in favour of fixing the docs but I'm not keen on changing the
> >> SQL syntax in a way that just kind of papers over part of the
> >> problems.
> >
> > I agree. I think that trying to design new SQL syntax at this point
> > is unlikely to be a good idea - we're just about out of time here, and
> > some people who might care about this are busy on other things, and
> > the deadline for patches that do new things has long since passed.
> > But I like the idea of trying to improve the documentation.
>
> Agreed. I think the documentation fixes definitely should be done, but
> understand that the grammar is a longer term issue with backward
> compatibility implications. Acknowledging the problem is the first step ;-)
+1
Thanks!
Stephen
Attachments:
[application/pgp-signature] signature.asc (819B, ../../[email protected]/2-signature.asc)
download
^ permalink raw reply [nested|flat] 9+ messages in thread
* Re: Changing references of password encryption to hashing
2017-03-10 02:16 Changing references of password encryption to hashing Michael Paquier <[email protected]>
2017-03-11 22:51 ` Re: Changing references of password encryption to hashing Joe Conway <[email protected]>
2017-03-13 08:48 ` Re: Changing references of password encryption to hashing Craig Ringer <[email protected]>
2017-03-16 13:19 ` Re: Changing references of password encryption to hashing Robert Haas <[email protected]>
2017-03-16 14:27 ` Re: Changing references of password encryption to hashing Joe Conway <[email protected]>
@ 2017-04-06 05:31 ` Noah Misch <[email protected]>
1 sibling, 0 replies; 9+ messages in thread
From: Noah Misch @ 2017-04-06 05:31 UTC (permalink / raw)
To: Joe Conway <[email protected]>; +Cc: Robert Haas <[email protected]>; Craig Ringer <[email protected]>; Michael Paquier <[email protected]>; pgsql-hackers
On Thu, Mar 16, 2017 at 07:27:11AM -0700, Joe Conway wrote:
> On 03/16/2017 06:19 AM, Robert Haas wrote:
> > On Mon, Mar 13, 2017 at 4:48 AM, Craig Ringer <[email protected]> wrote:
> >> So I'm in favour of fixing the docs but I'm not keen on changing the
> >> SQL syntax in a way that just kind of papers over part of the
> >> problems.
> >
> > I agree. I think that trying to design new SQL syntax at this point
> > is unlikely to be a good idea - we're just about out of time here, and
> > some people who might care about this are busy on other things, and
> > the deadline for patches that do new things has long since passed.
> > But I like the idea of trying to improve the documentation.
Seems like a good direction.
> Agreed. I think the documentation fixes definitely should be done, but
> understand that the grammar is a longer term issue with backward
> compatibility implications. Acknowledging the problem is the first step ;-)
Most of the user-visible (including doc/) proposed changes alter material
predating v10. Therefore, I've removed this from open item status.
--
Sent via pgsql-hackers mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
^ permalink raw reply [nested|flat] 9+ messages in thread
end of thread, other threads:[~2017-04-06 05:31 UTC | newest]
Thread overview: 9+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2017-03-10 02:16 Changing references of password encryption to hashing Michael Paquier <[email protected]>
2017-03-11 22:51 ` Joe Conway <[email protected]>
2017-03-13 07:11 ` Michael Paquier <[email protected]>
2017-03-13 08:48 ` Craig Ringer <[email protected]>
2017-03-16 03:19 ` Bruce Momjian <[email protected]>
2017-03-16 13:19 ` Robert Haas <[email protected]>
2017-03-16 14:27 ` Joe Conway <[email protected]>
2017-03-16 14:30 ` Stephen Frost <[email protected]>
2017-04-06 05:31 ` Noah Misch <[email protected]>
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox