Какова цель соли?

Question

В системе Linux пароли хранятся с использованием хеша MD5.Почему использование «соли» может защитить систему больше?В частности, я хочу прояснить следующие два

1. Соль, как говорят, хранится в виде простого текста с хешем, и как это может предотвратить атакующего, когда злоумышленник знает значение соли.(Атакующим может быть сам системный администратор, который может проверить /etc/shadow.
2. Если соль генерируется случайным образом каждый раз, как система может сравнивать хеш для аутентификации пользователя?

Например, пользователь A имеет пользовательскую соль s1 и генерирует h1; h1 = md5(password.s1);. В следующий раз он использует соль s2, и система должна сгенерировать другой хеш, h2 = md5(password.s2). Поскольку h1 не равен h2, как система можетаутентифицировать пользователя?

Answer 1

MD5, как вы знаете, является хешем, поэтому, если вы дадите ему ввод, например, «ПАРОЛЬ», вы получите уникальный (надеюсь, что в наши дни у MD5 коллизии) выход, например «3DE2AF ...».

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

Цель соли - добавить произвольные случайные данные к хешируемой строке, чтобы вы увеличили длину ввода до хэша. Это означает, что обычные радужные таблицы, которые ожидают преобразования только введенного пароля в хеш, не будут работать. Разумеется, что радужные таблицы являются просто обратными поисками, вы можете просто сгенерировать радужную таблицу, чтобы компенсировать все возможные выходные данные «пароль + соль». Это где увеличение длины вступает в свои права; из-за природы обращения хэшей, дисковое пространство для генерации реверсов для очень длинных хэш-входов вскоре становится неосуществимым. Буквенно-цифровые радужные таблицы на 6-8 символов - это уже пара гигабайт; увеличьте длину и классы символов, и вы начнете говорить кратно 10 ГБ.

Конечно, если вы солите с помощью 'ПАРОЛЯ' и хешируете 'ПАРОЛЬ', вы хэшируете 'ПАРОЛЬ', который не так уж безопасен, поэтому выбор соли также важен. В идеале вы должны использовать случайную соль с каждой хешированной строкой, но, конечно, вам нужно знать, что это такое. Обычный способ - получить соль из имени пользователя или другого свойства, уникального для этого случая. Добавление произвольных данных само по себе бесполезно; наличие пользовательских данных о соли теперь добавляет дополнительный уровень сложности, а это означает, что необходимы радужные таблицы со специализированным поиском для каждого пользователя. Чем больше вы усложняете, тем больше вычислительной мощности требуется. Вот где битва.

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

Редактировать подробнее здесь. См. crypt() для первого примера этого. @ CodeInChaos ссылается на PBKDF2 , который является частью PKCS # 5 . Более новая разработка - scrypt .

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

Редактировать 2 Уточнил мою запись соли - я думаю, что я танцевал вокруг ключевой проблемы дискового пространства раньше.

Answer 2

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

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

md5(md5(md5(password)));

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

md5(md5(md5(password+string)+string)+string);

Answer 3

Одной из причин может быть то, что если два человека используют один и тот же пароль по незнанию, они сгенерируют один и тот же MD5.Один из них может просто увидеть / etc / shadow и угадать пароль другого парня.

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

Answer 4

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