Re: You're on SecurityFocus.com for the cleartext passwords. - Mailing list pgsql-hackers

From Tom Lane
Subject Re: You're on SecurityFocus.com for the cleartext passwords.
Date
Msg-id 9457.957592021@sss.pgh.pa.us
Whole thread Raw
In response to Re: You're on SecurityFocus.com for the cleartext passwords.  (Vince Vielhaber <vev@michvhf.com>)
Responses Re: You're on SecurityFocus.com for the cleartext passwords.  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: You're on SecurityFocus.com for the cleartext passwords.  ("Sverre H. Huseby" <sverrehu@online.no>)
List pgsql-hackers
Vince Vielhaber <vev@michvhf.com> writes:
> ... I'm of the opinion now that we should look into encrypting the
> passwords.

I think it'd be a reasonable thing to work on.  I don't particularly
intend to be stampeded into doing something about it by "public
relations" pressure from people who would rather make inflated claims
than get their hands dirty by contributing a solution ;-).  (And, yes,
these claims are inflated.  If you don't trust your dbadmin, the
security of your password is the least of your worries --- the data
in your database may well be far more critical info than anything the
dbadmin could find in your personal account.  The general opinion on
the pghackers list has been that password-based security is the least
desirable of the authentication options we offer, anyway.  A security-
conscious site wouldn't even be using database passwords.)

The main potential hazard I see is portability.  Is crypt(3) available
on *all* the platforms Postgres runs on?  Does it give the same answers
on all those platforms?  If not, what shall we use instead?  Don't
forget that the frontend libraries have to have it too (or are you going
to keep transmitting passwords in cleartext?).  So that means you'd
better have it for Win, Mac, BeOS, etc, not just for dozens of Unix
variants --- and they *must* all give the same results.

There are also lesser worries about patents and US export regulations.
If we include an encryption package in the distribution we could
eliminate the portability problem, only to find ourselves facing
headaches in those departments :-(

So, by all means let's look for a solution ... but I suspect that
the cost/benefit ratio of fixing this is a lot higher than is being
claimed in some quarters.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: pg_group_name_index corrupt?
Next
From: Tom Lane
Date:
Subject: Re: http://www.postgresql.org/doxlist.html (fwd)