Re: Changing references of password encryption to hashing

On Sun, Mar 12, 2017 at 7:51 AM, Joe Conway <mail(at)joeconway(dot)com> wrote:
> 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.

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