Подтвердить что ты не робот

Соль и хеширование, почему бы не использовать имя пользователя?

Я должен признаться, что в основном не осведомлен о большинстве вопросов безопасности в области высоких технологий, имеющих отношение к веб-приложениям, но есть одна вещь, о которой я, по крайней мере, думал, что могу спросить, потому что это прямой вопрос (надеюсь) конкретного ответа.

Возьмите этот сайт: http://www.15seconds.com/issue/000217.htm

Он немного показывает, что они хранят значение соли в таблице, я понимаю принципы и математику, использую соль, но мне интересно:

  • Почему они не просто использовали имя пользователя как значение соли, а не генерировали его?
4b9b3361

Ответ 1

Поскольку имена пользователей имеют более низкую энтропию, чем случайная соль, поэтому они распространяют ваши хэши вокруг менее солидной соли.

Не то, чтобы пример на этой странице был очень впечатляющим. Я всегда создаю GUID и использую это.

Я подозреваю, что все это связано с шумом, поскольку безопасность в реальной жизни вызывает беспокойство, и даже довольно небольшое количество соли для каждого пользователя имеет большое значение для безопасности, при этом очень небольшие улучшения по мере того, как соль становится более сложной.

Ответ 2

Точка соли должна быть уникальной. Соль предназначена для предотвращения совместного использования затрат на атаку, то есть злоумышленник, пытающийся атаковать два хэшированных пароля менее чем вдвое дешевле, чем атаковать.

Одним из решений для обеспечения уникальности является создание случайной соли в достаточно широком пространстве. Следовательно, получение вдвое большей соли для двух разных экземпляров паролей достаточно маловероятно, что это не произойдет на практике.

Имя пользователя не является уникальным:

  • Имя пользователя не изменяется, когда пользователь меняет свой пароль. Злоумышленник, видя старый хешированный пароль, и новый хешированный пароль может атаковать как по стоимости, так и по цене, не превышающей вдвое большую стоимость атаки.
  • В данный момент имена пользователей уникальны в общесистемной, а не во всем мире. Существует много "боб" (в системе Unix, "root" ). Использование имени пользователя может позволить злоумышленнику атаковать несколько систем одновременно.

Солевая энтропия не очень важна, за исключением того, что она обеспечивает уникальность в условиях случайной генерации.

Ответ 3

Как насчет:

Salt = CryptoHash( CryptoHash(SubmittedEmailOrUsername) . CryptoHash(SubmittedPasswd) ) ?

Это казалось бы

  • имеют то преимущество, что не нужно хранить соль, поскольку она может быть динамически рассчитана,
  • имея при этом хорошую энтропию (вместо хэша вместо открытого текста) и

  • предоставляет соль, которая до тех пор, пока криптографический хеш, например 128-512 бит?

Одна из проблем заключалась бы в том, чтобы система разрешала двум пользователям иметь имя пользователя и пароль (например, не было бы с админом электронной почты), но есть ли какие-либо другие проблемы с этой схемой?