* Martijn van Oosterhout (kleptog@svana.org) wrote:
> On Fri, Dec 23, 2005 at 09:12:52AM -0500, Greg Stark wrote:
> > Eh? Just because you know everything the postmaster does doesn't mean you
> > can't be stopped. In the traditional unix password file scheme the crypt
> > string is public knowledge but it's not enough to log in. You need the
> > original password that crypts to that value.
>
> 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... :)
> These exist in the real world as PAP or CHAP, but there are many other
> examples. The reason it works in UNIX login is that the "in-the-clear"
> transit of the password is from the keyboard, via the kernel to a
> single process, not over a network, so it is considered secure. The
> login protocol for SMB has a similar flaw. If you can read the password
> file on an SMB server, you can login as any user. You may have to hack
> a client to make it work, but it is possible.
Well, and these days quite often the network connection is encrypted.
> PostgreSQL uses a variation where the cleartext password sent is just
> the md5 hash of the real password. It just stops the admin guessing it
> to see if the user is using it elsewhere. You really don't need the
> original password to login, just the hash.
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.
> The solution is obvious, public-key authentication which doesn't have
> these problems. eg SSH, SSL, etc... Or a trusted third party (ident).
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.
I guess to do that we'd have to make libpq under Windows have the option
of using the Windows SSPI layer. Anyone looked into this at all?
Anyone know if it'd have a chance of getting accepted?
Thanks,
Stephen