Еще один вопрос о соляных паролях

Question

Я знаю, что на SO есть тонны блогов, статей и вопросов о соляных паролях, но я не смог найти ответ на этот вопрос:

Если я генерирую парольхэш вроде этого:

$salt = randomString
$password = $_POST['password'] 
hashedPassword = sha1($password.$salt)

И у меня есть такая таблица:

Users
user_id | hashedPassword | salt

Почему злоумышленнику так сложно подобрать этот пароль?Разве они не могут просто использовать радужную таблицу или грубую силу, чтобы вычислить соль, а затем добавить соль к каждому слову в атаке по словарю?

Answer 1

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

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

, а затем добавляете соль к каждому слову в атаке по словарю?

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

Это, и только в этом вся соль.

Answer 2

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

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

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

Answer 3

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

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

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

Надеюсь, это поможет ...

Answer 4

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

Answer 5

Давайте рассмотрим простой пример: у нас есть две базы данных: Альфа и Бета :

Альфа просто хэширует пароль и сохраняетрезультат:

row: {
    passwordHash = Hash(password)
}

Beta создает случайное значение для каждого пользователя и использует его как часть ввода в хэш-функцию:

row: {
    salt = RandomString(),
    passwordHash = Hash(password + salt)
}

Теперь произнеситезлоумышленник заранее знает, что некоторые из ваших пользователей используют пароль: "password"

Чтобы найти всех пользователей в Alpha с паролем "password", вам нужно только вычислить хеш:"password" один раз.Вот пример из SQL:

DECLARE @Hash INT; SET @Hash = Hash("password");
SELECT UserID FROM Users WHERE passwordHash = @Hash

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

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

SELECT u.UserID FROM Users u WHERE u.passwordHash = Hash("password" + u.salt)

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

---

Вы уже знаете, что salt является мерой защиты от атак "радужного стола", поэтому ваш вопрос ... как?

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

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

Надеюсь, это когда-нибудь поможет читателю!