RE: [HACKERS] Updated TODO list

> > > Bruce Momjian <maillist(at)candle(dot)pha(dot)pa(dot)us> writes:
> > > >> DB admin has no business knowing other's passwords.
> The current security
> > > >> scheme is seriously flawed.
> > >
> > > > But it is the db passwords, not the Unix passwords.
> > >
> > > I think the original point was that some people use the
> same or related
> > > passwords for psql as for their login password.
> > >
> > > Nonetheless, since we have no equivalent of "passwd" that
> would let a
> > > db user change his db password for himself, it's a little silly to
> > > talk about hiding db passwords from the admin who puts them in.
> > >
> > > If this is a concern, we'd need to add both encrypted storage of
> > > passwords and a remote-password-change feature.
> >
> > Doing the random salt over the wire would still be a problem.
>
> And I don't like password's at all. Well, up to now the bare
> PostgreSQL doesn't need anything else. But would it really
> hurt to use ssl in the case someone needs security? I don't
> know exactly, but the authorized keys might reside in a new
> system catalog. So such a secure installation can live with a
> wide open hba.conf and who can be who is controlled by
> pg_authorizedkeys then.
>
> As a side effect, all communication between the backend and
> the client would be crypted, so no wire listener could see
> anything :-)

I've actually been using this on and off for a while. (I did some changes to
libpq some time back, so it no longer used fdopen() to access thins - in
preparation of SSL patches). Though not a complete implementation - just
that "if client certificate is trusted, then let'em in as whatever user they
say". But it shouldn't be too hard to finish off.

I'll try to get around to fix those patches up. The client-side
implementation was really ugly, and not at all "generic" (only worked in my
situation). Server-side was more generic. I'll try to fix the client-side
there..

//Magnus