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

Ответ 1

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

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

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

Ответ 2

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

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

Ответ 3

Первая атака, о которой я думаю, - это:

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

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

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

Ответ 4

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

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

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

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

Ответ 5

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

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

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

Это не то, о чем вы просили, а что-то для медитации:)

Ответ 6

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

Это не будет предотвращать атаку словаря, в отличие от популярного beleif. Это остановит простую атаку по словарю, но вполне возможно повторить словарь солями на учетную запись пользователя.

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

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

hashedPW = sha1(rawPassword + salt)

Вы бы сделали:

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

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

Ответ 7

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

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