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....  (Vince Vielhaber <vev@michvhf.com>)
Re: So we're in agreement....  (Philip Warner <pjw@rhyme.com.au>)
Список 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 по дате отправления:

Предыдущее
От: Vince Vielhaber
Дата:
Сообщение: Re: So we're in agreement....
Следующее
От: Hannu Krosing
Дата:
Сообщение: Re: You're on SecurityFocus.com for the cleartext passwords.