id: Гость   вход   регистрация
текущее время 18:56 08/12/2019
Автор темы: Гость, тема открыта 14/12/2014 22:07 Печать
Категории: криптография, хэширование, протоколы
http://www.pgpru.com/Форум/Криптография/КомпрометацияХэшаПароля
создать
просмотр
ссылки

Компрометация хэша пароля

Прошу помочь с ответом на простой вопрос, поскольку немного запарился. Пусть сервер хранит хэши от клиентских паролей с каким-то рандомным вектором h(pass,R1) и пусть кто-то взломал сервер и прочитал эти хэши. Как правило утверждается, что хранение хэшей пароля на сервере спасает от компрометации пароля при взломе сервера, но вообще то не спасает от
поддельной аутентификации, поскольку когда придет время вычислять h(R2,h(pass,R1)) на стороне клиента и сервера, сравнивая результаты, то взломщик решит задачу правильно, поскольку украл h(pass,R1), а R2 ему предоставит сервер или он его подслушал. Тогда какой резон утверждать про "отсутствие компрометации пароля", когда по факту взломщик зная хэш пароля всё равно успешно проходит аутентификацию на сервере под именем клиента?


 
Комментарии
— Гость (14/12/2014 23:53)   <#>
Если был порутан сервак, то да, конечно, будет скомпрометировано все.
Если был получен доступ к базе (например, sql-inj), то при аутентификации на сервер будет передан пароль, и там будет посчитано h(pass,R1). Почему вы считаете, что h(R2,h(pass,R1)) должно считаться у клиента? Если так реализовано, то конечно, h(pass,R1) само никогда не меняется и является, в некотором смысле, незасоленным паролем.
— SATtva (15/12/2014 11:36)   профиль/связь   <#>
комментариев: 11543   документов: 1036   редакций: 4092
Хранение хэшированных паролей может как перекрывать угрозу от компрометации базы, так и не перекрывать, в зависимости от фактического протокола аутентификации и поддержания сессии. Если в базе хранятся хэши паролей (без разницы, с солью или без), а клиент при аутентификации передаёт нехэшированный пароль, то такая схема устойчива к компрометации базы — противник получит только хэши, которые для аутентификации необходимо инвертировать.
— Гость (15/12/2014 14:38)   <#>

Что-то типа «length extension attack»?
— Гость (19/12/2014 01:06)   <#>
Почему вы считаете, что h(R2,h(pass,R1)) должно считаться у клиента?
Потому что рассматривается ситуация, когда h(R2,h(pass,R1)) вычисляется на клиенте и на сервере, чтобы сервер мог убедится в том, что клиент знает пароль.
Что-то типа «length extension attack»?
Удлиннения тут не причем, пример взят из статьи в Википедии,где много бестолковщины.
Хранение хэшированных паролей может как перекрывать угрозу от компрометации базы, так и не перекрывать,
В общем, совместить хранение только хэша на сервере и передачу только хэша пароля клиентом не получится?
— Гость (19/12/2014 01:12)   <#>
З.Ы. То есть невозможно хранить хэш пароля на сервере так, чтобы компрометация этого хэша не приводила к компрометации аутентификации, если аутентификация выполняется по хэшу же?
— SATtva (19/12/2014 08:25, исправлен 19/12/2014 08:25)   профиль/связь   <#>
комментариев: 11543   документов: 1036   редакций: 4092

Храните на сервере H(H(P)). В этом случае переданный клиентом хэш H(P) хэшируется сервером ещё один раз и сравнивается с записью базе. При этом, опять же, компрометация базы не позволяет использовать её содержимое для аутентификации.

Ваша оценка документа [показать результаты]
-3-2-1 0+1+2+3