Re: [pgadmin-hackers] Client-side password encryption - Mailing list pgsql-hackers

* Martijn van Oosterhout (kleptog@svana.org) wrote:
> On Fri, Dec 23, 2005 at 09:42:44AM -0500, Stephen Frost wrote:
> > * Martijn van Oosterhout (kleptog@svana.org) wrote:
> > > This isn't the first time this has been explained, but:
> > >
> > > With password encryption you essentially have two options:
> > >
> > > - Server knows password, use challenge-response authentication so
> > > password is not visible on wire.
> > > - Server only knows hash of password, password must be sent in clear
> > > over wire.
> >
> > Erm, Postgres isn't doing either of these...?  You even talk about what
> > Postgres does below so I'm kind of bemused that you don't mention it in
> > your list... :)
>
> Postgres *is* using one of these, the first one, where the server knows
> the authentication token (the md5 hash of the password). UNIX login
> uses the latter. Perhaps if you substitute "authentication token" for
> "password" above it makes it clearer?

Is it actually doing challenge-response where the challenge is different
each time?  I thought it just used the user's username or some such.
Point being- can an attacker use what's passed around on the network to
authenticate to the system directly?  If it's a random
challenge/response setup then they shouldn't be able to unless they
manage to convince the server to give it the same challenge (which
should be very difficult).

> > Well, and these days quite often the network connection is encrypted.
>
> If you use SSL or SSH? Sure. I think in that case you can setup
> pg_hba.conf to require "password" in which case the server will only
> accept an unhashed password.

Yeah, but you can't do both, which is the real annoyence.  You can't get
it to do the same as unix-based auth.

> > Stops the admin from guessing the password, but makes the text on the
> > disk *the* authentication token, meaning someone who manages to get a
> > copy of the password file gets full access to the system.
>
> If md5 auth is setup, yes.

Yeah, but the other alternative is clear-text passwords on the disk, not
something I really care for either, honestly.

> > There's also Kerberos, which I'm happy to say seems to be getting more
> > and more use.  I'd really like to get ODBC Kerberos working, at least
> > with MIT kerberos and then maybe someday (if I can manage to get it
> > working...) setup some cross-realm stuff with the Windows AD and SSPI
> > (iirc) things and have ODBC use that to authenticate against my
> > Linux-based PostgreSQL server.
>
> Yeah, I was counting kerberos under "trust a third party". It shouldn't
> be too hard to add other such systems, like PAM has been...

I don't know that I'd consider PAM under Postgres as really being PAM.
It's *only* password-checking, and there's the issue that Postgres
doesn't have a root process to do the PAM work under so the postgres
user has to be in shadow (which means all the Postgres processes can
read /etc/shadow, not exactly a nice setup) to have PAM work.  Perhaps
SASL and saslauthd could be an option for Postgres.  I'm not sure though
as I don't think the Postgres protocol currently supports the kind of
back-and-forth that both PAM and SASL want to be able to do for things
like password-expring, forced-password-changes, etc.
Thanks,
    Stephen