Re: encrypted passwords - Mailing list pgsql-hackers

Neil Conway <nconway@klamath.dyndns.org> writes:
> A couple questions regarding encrypted passwords:
> (1) There was talk of changing the default value of the
>     'password_encryption' GUC variable for 7.3; AFAIK, this hasn't
>     happened yet. Should this be done?

Hmm.  I thought it *was* done, but it looks like Bruce forgot to change
the actual guc.c value?  The docs and postgresql.conf.sample claim the
default is true...

2002-06-14 21:29  momjian
* doc/src/sgml/runtime.sgml,src/backend/utils/misc/postgresql.conf.sample: Make encryption ofstored passwords the
default,as discussed months ago.
 

Seem to be one file short on that commit ...


> (2) What is the reasoning behind the current storage format of
>     MD5-encrypted passwords?

The reasoning for the apparent leakage between encrypted and unencrypted
formats is it allows pg_dumpall to reload an already-encrypted password,
or an admin to copy-and-paste an encrypted password without knowing
exactly what the password is.  See the archives when this mechanism was
being designed (about a year ago I think), if you want the full story.

>         (b) it makes it difficult to determine if the password is
>             *actually* encrypted, or whether the user just happened to
>             specify an (unencrypted) password of that form.

By definition, if it looks like that then it's encrypted.  I really
doubt anyone will want to use a 35-character plaintext password...
the apparent conflict is not going to happen in practice AFAICS.

>         (c) it limits us to using the MD5 algorithm.

Nonsense.  If we want another method, we just use another prefix.

> (3) (Related to 2b above) Shouldn't we reject an attempt by the user
>     to specify an un-encrypted password that matches the isMD5() test?

No, see above.  There are actually three cases here: entering a
previously encrypted password (in which case do nothing to it regardless
of the "encrypted" option), entering an uncrypted password with the
"encrypted" option (apply MD5 transform), or entering an uncrypted
password with the "unencrypted" option (do nothing).

I suppose we could have instead invented an ALREADY_CRYPTED option
instead, but we didn't, for reasons I don't recall at the moment;
but I think it had something to do with making life easier for
pg_dumpall.

> (4) The naming standard for system catalogs would dictate that the
>     'passwd' field of pg_shadow actually be named 'usepasswd' or
>     something similar, wouldn't it? The same applies to the 'valuntil
>     field.

Yeah, they are both ancient mistakes.  It's not worth trying to fix now
however; we'd just break client queries.
        regards, tom lane