Re: You're on SecurityFocus.com for the cleartext passwords.
От | Tom Lane |
---|---|
Тема | Re: You're on SecurityFocus.com for the cleartext passwords. |
Дата | |
Msg-id | 11175.957638617@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: You're on SecurityFocus.com for the cleartext passwords. (Benjamin Adida <ben@mit.edu>) |
Ответы |
Re: You're on SecurityFocus.com for the cleartext passwords.
|
Список | pgsql-hackers |
Benjamin Adida <ben@mit.edu> writes: > Okay, my understanding was that the protocol would work as follows: > - client requests login > - server sends stored salt c1, and random salt c2. > - client performs hash_c2(hash_c1(password)) and sends result to server. > - server performs hash_c2(stored_pg_shadow) and compares with client > submission. > - if there's a match, there's successful login. Oh, now I see. OK, that looks like it would work. It would definitely mean a change of algorithm on the client side. Probably the way to attack this would be to combine MD5 and this double password-munging algorithm as a new authentication protocol type to add to the ones we already support. That way old clients don't have to be updated instantly. OTOH, if the password stored in pg_shadow is MD5-encrypted, then we lose the ability to support the old crypt-based auth method, don't we? Old clients could be successfully authenticated with cleartext password challenge (server MD5's the transmitted password and compares to pg_shadow), but we couldn't do anything with a crypt()-encrypted password. Is that enough reason to stay with crypt() as the underlying hashing engine? Maybe not, but we gotta consider the tradeoffs... regards, tom lane
В списке pgsql-hackers по дате отправления: