Re: So we're in agreement....
От | Tom Lane |
---|---|
Тема | Re: So we're in agreement.... |
Дата | |
Msg-id | 19075.957728049@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: So we're in agreement.... (Vince Vielhaber <vev@michvhf.com>) |
Ответы |
Re: So we're in agreement....
Re: So we're in agreement.... |
Список | pgsql-hackers |
Vince Vielhaber <vev@michvhf.com> writes: > You're right, it wouldn't work. It should've been like this: > CLIENT: md5(salt_from_server + md5(username + password))) > SERVER: md5(salt_from_server + stored_password) > The "salt_from_server" is your random salt. The fixed salt is the > username. You're still not getting the point. I refer you to Ben Adida's original, correct description of the way to do this: > - 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. There have to be *two* random salts involved, one chosen when the password was set (and used to cloak the stored password against people with access to pg_shadow) and one chosen for the duration of this password challenge (and used to cloak the challenge transaction against people sniffing the packet traffic). If you give up either one of those bits of randomness then you lose a great deal. Using the username instead of an independent random value to salt the stored password is not a small change, it is a fundamental weakening of the security system. If you don't see that this is so then you don't understand anything about cryptography. regards, tom lane
В списке pgsql-hackers по дате отправления: