Re: [HACKERS] Changing references of password encryption to hashing - Mailing list pgsql-hackers

From Joe Conway
Subject Re: [HACKERS] Changing references of password encryption to hashing
Date
Msg-id 036316d5-a707-3f26-2ad2-8a63a8ff3f5f@joeconway.com
Whole thread Raw
In response to [HACKERS] Changing references of password encryption to hashing  (Michael Paquier <michael.paquier@gmail.com>)
Responses Re: [HACKERS] Changing references of password encryption to hashing  (Michael Paquier <michael.paquier@gmail.com>)
Re: [HACKERS] Changing references of password encryption to hashing  (Craig Ringer <craig@2ndquadrant.com>)
List pgsql-hackers
On 03/09/2017 06:16 PM, Michael Paquier wrote:
> As discussed here:
> https://www.postgresql.org/message-id/98cafcd0-5557-0bdf-4837-0f2b7782d0b5@joeconway.com
> 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


pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: [HACKERS] Need a builtin way to run all tests faster manner
Next
From: Andres Freund
Date:
Subject: [HACKERS] src/test/regress's check-prepared-txns target