* Martijn van Oosterhout ([email protected]) wrote: > On Fri, Dec 23, 2005 at 09:42:44AM -0500, Stephen Frost wrote: > > * Martijn van Oosterhout ([email protected]) 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
signature.asc
Description: Digital signature
