Re: Changing references of password encryption to hashing

From: Joe Conway <mail(at)joeconway(dot)com>
To: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Changing references of password encryption to hashing
Date: 2017-03-11 22:51:52
Message-ID: 036316d5-a707-3f26-2ad2-8a63a8ff3f5f@joeconway.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2017-03-11 23:00:17 src/test/regress's check-prepared-txns target
Previous Message Andres Freund 2017-03-11 22:36:56 Re: Need a builtin way to run all tests faster manner