Вопрос по security, hash, language-agnostic – Являются ли соли бесполезными для безопасности, если злоумышленник знает их?

10

Допустим, у меня есть таблица пользователей, настроенная так:

CREATE TABLE `users` (
    `id` INTEGER PRIMARY KEY,
    `name` TEXT,
    `hashed_password` TEXT,
    `salt` TEXT
)

Когда пользователь создан, случайно сгенерированная соль производится и сохраняется в базе данных вместе с результатами чего-то вродеget_hash(salt + plaintext_password).

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

Ваш Ответ

7   ответов
2

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

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

Допустим, вы хотите зашифровать слово «секрет». После того, как он зашифрован, скажем, что теперь он выглядит как этот 00110010.

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

Если сначала ввести слово «соль» («saltsecret»), теперь зашифрованное значение будет выглядеть по-другому, и хакер не найдет его в таблице поиска.

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

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

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

что атака перебором алгоритмов MD5, SHA1, SHA256 с графическим процессором имеет пропускную способность более 1 млрд. Попыток в секунду, а SHA512 - около 300 М / с. Если вы используете один из этих алгоритмов, это замедлит хакера, который использовал радужную таблицу (менее вероятно), но не замедлит хакера, который использовал атаку грубой силой (более вероятно). Это определенно не защитит вас, это только добавит немного защиты от устаревшего радужного стола (для этого алгоритма). Немного лучше, чем ничего.

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

Have a look at this статья и подвести итог:

If you are a user:

Make sure all your passwords are 12 characters or more, ideally a lot more. I recommend adopting pass phrases, which are not only a lot easier to remember than passwords (if not type) but also ridiculously secure against brute forcing purely due to their length.

If you are a developer:

Use bcrypt or PBKDF2 exclusively to hash anything you need to be secure. These new hashes were specifically designed to be difficult to implement on GPUs. Do not use any other form of hash. Almost every other popular hashing scheme is vulnerable to brute forcing by arrays of commodity GPUs, which only get faster and more parallel and easier to program for every year.

Posted by Jeff Atwood

8

по крайней мере, стало популярным) в файле UNIX / etc / passwd, который был доступен для чтения всему миру. Обычно предполагается, что соль, а также зашифрованный пароль известны взломщику. Цель соли - замедление процесса взлома (поскольку один и тот же пароль не будет сопоставлен с одной и той же зашифрованной строкой); этоnot секрет сам по себе.

4

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

Лучший способ предотвратить перебор - просто использовать длинные и сложные пароли.

1

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

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

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

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

17

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

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

вопрос спрашивает, знает ли злоумышленник соль
Ответ Люка предполагает, что злоумышленник знает соль. Дело в том, что злоумышленник, не имея никакой соли, может просто найти хешированный пароль в радужной таблице, которую они нашли в сети. С добавлением соли, злоумышленник должен сделать грубую силу самостоятельно.
@Mitch: Предварительно вычислить все возможные хеши MD5 (чтобы дать небезопасный пример) паролей длиной до n символов легко. Соление является хорошим, потому что предварительное вычисление такого количества паролей * количества возможных солей невозможно. Соль не спрятана.
Важный момент: размер соли должен быть выбран достаточно большим, чтобы у атакующего не могло быть достаточно большого радужного стола. Очевидно, что 8 битов соли абсолютно не предотвратят атаку радужных таблиц, просто увеличьте требуемый размер таблицы не более чем в 25 раз. 128 битов случайной соли, ооо, исключают радужные таблицы сейчас и навсегда.

Похожие вопросы