Какова цель соли?
В системе Linux пароли хранятся с использованием хеша MD5. Почему использование "соли" может защитить систему больше? В частности, я хочу прояснить следующие два
- Говорят, что соль хранится в виде простого текста с хешем, и как это может предотвратить атакующего, когда злоумышленник знает значение соли.
(Атакующим может быть сам системный администратор, который может проверить
/etc/shadow, - Если соль генерируется случайным образом каждый раз, как система может сравнить хеш для аутентификации пользователя?
Например, пользователь A имеет пользовательскую соль s1 и генерирует h1; h1 = md5(password.s1);, В следующий раз он использует соль s2, и система должна сгенерировать другой хеш, h2 = md5(password.s2), Поскольку h1 не равно h2, как система может аутентифицировать пользователя?
4 ответа
Как вы знаете, MD5 - это хеш, поэтому, если вы дадите ему ввод, например, "ПАРОЛЬ", вы получите уникальный (надеюсь, что в наши дни у MD5 коллизии) выход, например "3DE2AF...".
Теперь, как вы знаете, довольно трудно прямо изменить это, пока кто-то не подумает... подождите, почему бы мне не сгенерировать все возможные комбинации значений хеширования, пока я не смогу обратить вспять хэш. Это называется радужным столом.
Целью соли является добавление произвольных случайных данных к хешируемой строке, так что вы увеличиваете длину ввода до хеша. Это означает, что обычные радужные таблицы, которые ожидают преобразования только введенного пароля в хеш, не будут работать. Разумеется, что радужные таблицы являются просто обратными поисками, вы можете просто сгенерировать радужную таблицу, чтобы компенсировать все возможные выходные данные "пароль + соль". Это где увеличение длины вступает в свои права; из-за природы обращения хэшей, дисковое пространство для генерации реверсов для очень длинных входов хэша вскоре становится неосуществимым. Буквенно-цифровые радужные таблицы на 6-8 символов - это уже пара гигабайт; увеличьте длину и классы символов, и вы начнете говорить кратно 10 ГБ.
Конечно, если вы солите "PASSWORD" и хэшируете "PASSWORD", вы хэшируете "PASSWORDPASSWORD", который не намного безопаснее, поэтому выбор соли также важен. В идеале вы должны использовать случайную соль с каждой хешированной строкой, но, конечно, вам нужно знать, что это такое. Обычный способ - получить соль из имени пользователя или другого свойства, уникального для этого случая. Добавление произвольных данных само по себе бесполезно; наличие пользовательских данных о соли теперь добавляет дополнительный уровень сложности, что означает, что необходимы радужные таблицы со специализированным поиском для каждого пользователя. Чем больше вы усложняете, тем больше вычислительной мощности требуется. Вот где битва.
Тем не менее, есть некоторые современные методы. Я не эксперт, поэтому не могу сказать вам, насколько они безопасны, но о них стоит упомянуть. Концепция медленного хеширования. По сути, с помощью сложных хеш-функций вы заставляете время вычислять каждый хеш. Таким образом, возможность каждого пользователя проверять пароль теперь имеет постоянное количество времени, добавляемое для каждого пароля, который вы хотите проверить. Если вы брутфорс, это плохие новости (тм). Точно так же, если система хорошо спроектирована, если нет ярлыков (которые, вероятно, приравнены к слабостям), то генерация радужной таблицы для медленной хэш-функции также должна занять некоторое время.
Отредактируйте более подробно здесь. Увидеть crypt() для первого примера этого. CodesInChaos ссылается на PBKDF2, который является частью PKCS # 5. Более новая разработка - Scrypt.
Как я уже сказал, я не эксперт по криптоаналитику. В последнем примере у меня нет специальных знаний о его пригодности, я просто показываю вам, к чему все идет.
Редактировать 2 Разъяснил мою запись соли - я думаю, что я танцевал вокруг ключевой проблемы дискового пространства раньше.
Вы можете изменить простой алгоритм хеширования грубой силой.
Если вы используете общее слово для паролей, некоторые таблицы предварительной сборки (например, радужные) могут содержать их. Вот почему большинство алгоритмов вызывают хеш-функцию несколько раз:
md5(md5(md5(password)));
Использование соли дает гораздо больше случайности сгенерированному паролю и, следовательно, делает его менее угадываемым. Он состоит из добавления случайного куска строки в процессе
md5(md5(md5(password+string)+string)+string);
Одна из причин может заключаться в том, что если два человека неосознанно используют один и тот же пароль, они генерируют один и тот же MD5. Один из них может просто увидеть /etc/shadow и угадать пароль другого парня.
Теперь с солью, добавленной к каждому паролю, даже одни и те же пароли генерируют разные хэши.
Когда вы зашифровываете данные, они все еще могут быть атакованы атаками Брюса и Радуги. При засолке в конце зашифрованных данных вы добавляете несколько дополнительных битов. Таким образом, злоумышленник не может получить исходные данные должным образом.