* Greg Stark (gsstark@mit.edu) wrote:
> Stephen Frost <sfrost@snowman.net> writes:
> > With the 'md5' method the server will send will send a randomly
> > generated salt to the client which will then concatenate the user's name
> > to the password, perform an md5 on that result, then concatenate the
> > result of the md5 to the salt provided by the server and will then md5
> > that.
>
> I think that in this case calling it a salt altogether is wrong. It's a
> "challenge".
Ah, yeah, you're right.
> And I'm inclined to suggest that this authentication method be removed
> altogether. The security flaw is that it exists at all. Not the details of the
> implementation.
I'm not quite sure it's as dire as all that. It's intended to solve a
different problem. As I recall, Kerberos does much the same, it takes
the password, the user's princ, performs a hash and uses *that* as
password-equiv by using it as the key to encrypt with. One big reason
why you had better be *very* careful with your KDC, and why the KDC
encrypts its database again with the Master KDC password. Additionally,
KDCs can be locked down and you can pretty easily set up slaves of them
for backup purposes and just not put the Master KDC password on the
system anywhere and type it in by hand when bringing up the system.
Unfortunately, Postgres doesn't currently encrypt pg_shadow and even if
it did you'd have to have the password stored on disk somewhere in the
clear if you wanted the database to start automatically, which is more
important if you havn't got backup databases and whatnot (which aren't
really as easy to set up w/ Postgres and generally Postgres requires
more disk space than a KDC).
Stephen
