Thread

Re: Encrypting pg_shadow passwords

Jim Mercer <jim@reptiles.org> — 2001-06-15T21:42:22Z

> > In a release or three we could discontinue support for old-style crypt,
> > but I think we must allow a transition period for people to update their
> > clients.
> 
> Yes, MD5 is something that probably should be done at the same time to
> minimize disruption.

while we are on the subject of auth and password and crypt, i noticed some
time ago, that there was an inconsistency in the way the auth passwd/crypt
stuff worked.

we have:

  host  dbname x.x.x.x x.x.x.x password somefile

this method takes a clear-text password from the client, encrypts it
and compares it against the matching second field of "somefile"
ie. somefile is a traditional /etc/passwd style file

i like to think of this as "telnet" authentication, user/passwd in clear text.
server stores pre-encrypted passwords.

and i use it for access from my php scripts, thus avoiding the necessity of
giving "webuser" access to my tables, and setting up some kinda secondary
authentication table.

the docs in pg_hba.conf lead you to believe that if you leave off "somefile",
then it does the same thing, but compares against pg_shadow.

however, and i don't know that this was intentional, but if you leave
"somefile" off, it compares the plain-text user password against the raw
value of the pg_shadow passwd field.

i wanted a behaviour as above, encrypt the clear text, and compare against
the stored pre-encrypted password in pg_shadow.

given that there are many installations which may be using things as they
are, i have created a set of patches which do:

  host  dbname x.x.x.x x.x.x.x password pg_shadow

(pg_shadow is a "reserved word, similar to the way "sameuser" is used with
ident)

this method takes a clear-text password from the client, encrypts it
and compares it against the password stored in pg_shadow.

this method should not conflict with anyone, except those who actually
want to use a /usr/local/pgsql/data/pg_shadow as their passwd file.
(i seem to recall previous versions actually stored the user data in
that specific file, although it was not in /etc/passwd format)

in my opinion, this method allows you to have pgusers which are wholy
seperate from /etc/passwd users.  and allows you to manage them entirely
within postgresql.

you can have a front end which does a
CREATE USER joe WITH PASSWORD 'crypto-gunge';

[ patch attached ]

-- 
[ Jim Mercer        jim@reptiles.org         +1 416 410-5633 ]
[ Now with more and longer words for your reading enjoyment. ]