Re: Documentation for CREATE USER
| От | Phil Olson |
|---|---|
| Тема | Re: Documentation for CREATE USER |
| Дата | |
| Msg-id | CANnr0A2-dfEvwiLG=vnj=PDbA_5NfGSWutEBBXZVgSovFmw3ow@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: Documentation for CREATE USER (Josh Kupershmidt <schmiddy@gmail.com>) |
| Список | pgsql-docs |
*forgot to reply-all
I appreciate the feedback. I do understand in the scheme of things, this is very low priority so I'll entrust the final say with you guys and refrain from following up beyond this email.
> I'm not sure whether a doc is needed
I appreciate your time,
Phil
[1]
http://www.postgresql.org/message-id/7083.1200929593@sss.pgh.pa.us
[2]
http://www.postgresql.org/docs/9.3/static/tutorial-join.html
I appreciate the feedback. I do understand in the scheme of things, this is very low priority so I'll entrust the final say with you guys and refrain from following up beyond this email.
> I'm not sure whether a doc is needed
It should avoid threads such as the one I first emailed about seen in [1]. In most contexts, if I had the option to "encrypt" a password and the only choice of method was md5 - it begs to be googled "why"
> or where it [documentation] should go if it is
I figure it would be placed in as a note, similarly to the note seen below "Joins Between Tables" found at [2]
> I don't agree with the characterization of md5 hashing with a salt as being "simply obfuscated"
My point here is that given the developer's comments seen in [1]
"
So the only reason we bother with hashing here is to keep a superuser from finding out your cleartext password, which might possibly let him crack into non-database services that you foolishly used the same password for
"
Hashing is the means to reach an effectively obfuscated string of text (general definition of the word: "render obscure, unclear, or unintelligible.").
> or where it [documentation] should go if it is
I figure it would be placed in as a note, similarly to the note seen below "Joins Between Tables" found at [2]
> I don't agree with the characterization of md5 hashing with a salt as being "simply obfuscated"
My point here is that given the developer's comments seen in [1]
"
So the only reason we bother with hashing here is to keep a superuser from finding out your cleartext password, which might possibly let him crack into non-database services that you foolishly used the same password for
"
Hashing is the means to reach an effectively obfuscated string of text (general definition of the word: "render obscure, unclear, or unintelligible.").
I appreciate your time,
Phil
[1]
http://www.postgresql.org/message-id/7083.1200929593@sss.pgh.pa.us
[2]
http://www.postgresql.org/docs/9.3/static/tutorial-join.html
On Tue, Oct 14, 2014 at 11:22 AM, Josh Kupershmidt <schmiddy@gmail.com> wrote:
On Thu, Oct 9, 2014 at 5:29 PM, Phil Olson <philip.olson.m@gmail.com> wrote:
> In short, I think it should be made clear that an encrypted user password
> for all intents and purposes, is simply obfuscated.
Well, I do agree that "encrypted" is a misleading word to use in this
context, since "hashed" is the technically correct description of what
gets stored in pg_authid.rolpassword when one uses:
CREATE ROLE ... WITH ENCRYPTED PASSWORD 'secret'
Though of course it's too late to change the SQL syntax we accept. And
I'm not sure whether a doc change is needed, or where it should go if
it is -- the section on pg_authid [1] already accurately spells out
how we store rolpassword when the ENCRYPTED option is given. Possibly
that description could be a bit more clear about the fact that
"possibly encrypted" is talking about the 'ENCRYPTED' option of CREATE
ROLE.
I don't agree with the characterization of md5 hashing with a salt
(not a particularly strong salt choice, but a salt nonetheless) as
being "simply obfuscated". Here's a short summary of how obfuscation
vs. hashing vs. encryption are generally distinguished:
http://stackoverflow.com/a/184369/1772673
> Encrypted implies secure,
See link above, "encrypted" has a basically well-understood definition.
Josh
[1] http://www.postgresql.org/docs/current/static/catalog-pg-authid.html
В списке pgsql-docs по дате отправления: