* Greg Stark ([EMAIL PROTECTED]) wrote: > Stephen Frost <[EMAIL PROTECTED]> 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
signature.asc
Description: Digital signature