Соль, пароли и безопасность
Я прочитал многие вопросы на ТАК об этом, но много ответов противоречат друг другу, или я не понимаю.
Необходимо всегда хранить пароль как хеш, никогда как простой текст. Но если Вы храните соль (уникальный для каждого пользователя) рядом с хешированным password+salt в базе данных. Это не кажется очень умным мне как разве, кто-то не мог получить доступ к базе данных, искать, говорит, что учетная запись под названием Администратор или безотносительно и затем разрабатывает пароль от этого?
5 ответов
Многие люди говорят " остановить радужные таблицы », не объясняя, что делают радужные таблицы и почему это их останавливает.
Радужные таблицы - это умный способ предварительно вычислить большое количество хэшей и сохранить их в меньшем объеме памяти, чем наивно потребовалось бы, и вы можете использовать их для очень быстрого обращения хэша. Таблицы для простых функций, таких как hash = md5 (пароль) и hash = sha1 (пароль) , являются общими.
Однако они могут быть сгенерированы для ЛЮБОЙ хэш-функции, которая может быть описана как output = f (input) . Если вы используете соль всего сайта для всех паролей пользователей, например hash = md5 (соль + пароль) , вы можете создать функцию f , f (пароль) = md5 (соль + пароль) . Таким образом, вы можете создать радужные таблицы для этой функции, что займет много времени, но позволит очень быстро взламывать каждый пароль в базе данных.
Если соль для каждого пароля различна, вы не сможете создать радужную таблицу, которая взломает все пароли в базе данных.Вы можете создать новый для каждого пользователя, но это будет бессмысленно - наивный брутфорс не будет медленнее. Таким образом, наличие отдельной соли для каждого пользователя останавливает атаку радужных таблиц.
Есть несколько способов сделать это. Популярные способы:
- Отдельная соль для каждого пользователя, хранящаяся вместе с другими данными в базе данных:
hash = hashfunction (salt + password) - Глобальная соль и некоторое уникальное значение для каждого пользователя:
hash = hashfunction (salt + password + user_id)например - Глобальная соль и соль для каждого пользователя:
hash = hashfunction (global_salt + user_salt + password)
Наличие глобальной соли может добавить небольшая дополнительная сложность для взлома паролей, поскольку они могут храниться вне базы данных (например, в коде), к которой злоумышленники могут не получить доступ в случае взлома базы данных. Криптографически я не думаю, что это добавляет много, но на практике это может замедлить их.
Наконец, чтобы ответить на ваш вопрос:
Хранение соли вместе с пользовательскими данными не ослабляет хэш. Хеш-функции односторонние: учитывая хеш-код пароля, даже несоленого, очень сложно найти этот пароль. Мотивация соления заключается не в том, чтобы сделать отдельный хэш более безопасным, а в том, чтобы сделать сбор нескольких хешей более безопасным.Существует несколько векторов атаки на набор несоленых хэшей:
- Радужные таблицы
- Хеширование общих паролей (
123,пароль,бог) и проверка наличия каких-либо в базе данных, а затем взлом этих учетных записей - Ищите идентичные хэши в базе данных, что означает идентичные пароли (возможно)
Соль предназначена для нарушения существующих радужных таблиц. Знать соль - не угроза безопасности. Если вы знаете соль, вам все равно нужно знать пароль.
Если вы не храните соль, как вы проверите, был ли введен правильный пароль?
Ну, прежде всего, основная цель соли - отключить перебор паролей, например, она предотвращает использование радужных таблиц для быстрого компрометация пароля.
Даже если злоумышленник получит доступ к базе данных, не так просто определить настоящие пароли из солей (особенно если у вас нет кода и вы не знаете, как хешируется пароль). Однако для дополнительной безопасности я предпочитаю хешировать пароль со статическим хешем, указанным в коде. Таким образом, недостаточно скомпрометировать базу данных. Пример такого метода (в PHP):
$hashed_password = sha1($user_password . $user_salt . $static_salt);
$ user_salt - это соль в базе данных, уникальная для каждого пользователя, $ static_salt - это соль, указанная где-то в настройках вашего кода.
Соль используется для увеличения времени, которое злоумышленник должен будет потратить на поиск пароля, соответствующего хэшу, хранящемуся в базе данных. Обычно для этого используется таблица поиска, такая как таблица радуги (см. http://en.wikipedia.org/wiki/Rainbow_table ).
Время требует не самого поиска, а времени для вычисления радужной таблицы. Добавление соли вынуждает злоумышленника пересчитать новую радужную таблицу, даже если злоумышленник знает, кто скомпрометирует базу данных