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

Поиск
Список
Период
Сортировка
От Joe Conway
Тема Re: [HACKERS] Changing references of password encryption to hashing
Дата
Msg-id 036316d5-a707-3f26-2ad2-8a63a8ff3f5f@joeconway.com
обсуждение исходный текст
Ответ на [HACKERS] Changing references of password encryption to hashing  (Michael Paquier <michael.paquier@gmail.com>)
Ответы Re: [HACKERS] Changing references of password encryption to hashing
Re: [HACKERS] Changing references of password encryption to hashing
Список 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 по дате отправления:

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: [HACKERS] Need a builtin way to run all tests faster manner
Следующее
От: Andres Freund
Дата:
Сообщение: [HACKERS] src/test/regress's check-prepared-txns target