Re: Encrypting pg_shadow passwords - Mailing list pgsql-hackers

I am replying to the original message because it has all the relevant
information.  The problem with 'password' authentication is that the
password goes across the wire in plaintext.  Now, if we start to ship
encrypted passwords across the wire, but use the same salt for every
authentication request, we are really no more secure than if we sent it
in the clear.

If a user specifies 'crypt' in pg_hba.conf, they should be assured that
the password is safe in case someone snoops it.  Encrypting pg_shadow
and comparing that with the same salt every time is not secure from
snooping so we don't allow it.

Am I missing something?

> > > 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. ]
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 6: Have you searched our list archives?
> 
> http://www.postgresql.org/search.mpl
> 

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026