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 по дате отправления: