Можно ли атаковать пароль пользователя известной солью?

Question

Мне сказали, что электронная почта - плохая соль, потому что она не уникальна и не связана с пользователем.
И если пользователь использует один и тот же пароль на 2 сайтах, хеш будет одинаковым.

Итак, что с ним не так? что такое сценарий атаки?
Предположим, у нас есть и хеш, и соль. Таким образом, другой сайт имеет такой же хэш в своей базе данных. Как мы можем навредить этому пользователю на другом сайте? Можем ли мы вообще?

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

Я не собираюсь ничего ломать. Я задаю этот вопрос в контексте этого: электронная почта или (временная метка регистрации) хорошая соль?

Определенные и практические ответы, пожалуйста.

Answer 1

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

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

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

Answer 2

Это в основном теоретический вопрос.Итак, как работает «взлом хэшированной стоимости»?Существуют так называемые «радужные таблицы», которые представляют собой просто список с общими словами и их хэш-значением.Для соленых хешей атакующим нужны такие таблицы также с солеными хешами.Таким образом, теоретически с уникальными солями для каждого пользователя злоумышленнику нужна одна таблица для каждого соли (=> пользователь).Если у вас есть статическая соль, ему «просто» нужна одна таблица для вашей базы данных.Создание таких таблиц довольно дорого, поэтому в большинстве случаев не стоит создавать его только для одной страницы.

Вывод: (конечно) безопаснее использовать уникальные соли для каждого пользователя, но наочень высокий уровень.Статические соли обычно "достаточно безопасны".

Answer 3

Первая атака, о которой я могу подумать:

• пользователь имеет одинаковую соль и пароль на двух сайтах
• на обоих сайтах есть недостаток, позволяющий читать засоленные пароли
• один сайт облегчает чтение пароля или грубое угадывание пароля

Злоумышленник может быстро просмотреть идентичные соленые пароли на обоих сайтах и ​​найти пользователей с одинаковыми паролями на обоих сайтах. Затем прочитайте пароль или угадайте пароль на более слабом сайте и используйте его на более безопасном сайте.

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

Answer 4

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

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

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

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

Answer 5

Предположим, что у хакера есть и пароль, и соль, и доступ к вашей формуле хеширования.

Это НЕ предотвратит атаку по словарю, в отличие от популярного белейфа.Это остановит простую атаку по словарю, но итерация словаря с солями для каждой учетной записи пользователя вполне возможна.

См .: Почему соли делают атаки по словарю «невозможными»? для получения дополнительной информации.

Вот почему, когда вы генерируете хеш пароля, а не хешируете один раз с солью, IE:

hashedPW = sha1(rawPassword + salt)

Вы должны сделать:

hashedPW = sha1(rawPassword + salt)
for i = 0; i < 2000; i++){
    hashedPW = sha1(hashedPW + salt)
}

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

Answer 6

Если соль уже известна, значит, у вас большие проблемы.

http://en.wikipedia.org/wiki/Rainbow_attack

Answer 7

Не могу реально помочь вам с точки зрения безопасности, но если вы посмотрите на vBulletin, например, каждый пользователь получает свою собственную сгенерированную соль, которую он использует для шифрования пароля следующим образом:

$password = md5(md5($clear_password) + $salt);

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

Это не то, о чем вы просили, а то, над чем нужно медитировать:)