Соль, пароли и безопасность

Ответ 1

Многие люди говорят "остановить столы радуги", не объясняя, что делают таблицы радуги или почему это останавливает их.

Таблицы Rainbow - это умный способ предварительного вычисления большого количества хэшей и хранения их в меньшем объеме памяти, чем это было бы наивно необходимо, и вы можете использовать их для очень быстрого изменения хэша. Таблицы для голой функции, такие как hash = md5(password) и hash = sha1(password), являются общими.

Однако они могут быть сгенерированы для ЛЮБОЙ хеш-функции, которая может быть описана как output = f(input). Если для всех пользовательских паролей используется соль сайта, например hash = md5(salt+password), вы можете построить функцию f, f(password) = md5(salt+password). Поэтому вы можете генерировать таблицы радуги для этой функции, что займет много времени, но позволит вам быстро взломать каждый пароль в базе данных.

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

Есть несколько способов сделать это. Популярные способы включают в себя:

• Отдельная соль для каждого пользователя, хранящаяся рядом с их другими деталями в базе данных: hash = hashfunction(salt + password)
• Глобальная соль и уникальное значение для пользователя: hash = hashfunction(salt + password + user_id) например
• Глобальная соль и соль для каждого пользователя: hash = hashfunction(global_salt + user_salt + password)

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

Наконец, чтобы ответить на ваш реальный вопрос:

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

• Таблицы Rainbow
• Хеширование общих паролей (123, password, god) и просмотр, если они существуют в базе данных, а затем компрометация этих учетных записей
• Ищите идентичные хэши в базе данных, что означает идентичные пароли (возможно)

Ответ 2

Соль используется для увеличения времени, которое атакующий должен будет тратить, чтобы найти пароль, соответствующий хешу, хранящемуся в базе данных. Для этого используется таблица поиска, такая как таблица радуги (см. http://en.wikipedia.org/wiki/Rainbow_table).

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

Ответ 3

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

Ответ 4

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

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

$hashed_password = sha1($user_password . $user_salt . $static_salt);

$user_salt - это соль в базе данных, уникальная для каждого пользователя, $static_salt - это соль, указанная в ваших настройках кода где-то.

Ответ 5

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

• Почему соль?
• Почему соль хранится вместе с хешем (пароль + соль).

Вот мое понимание.

• У хакеров есть радужный стол для всех словарных слов, которые он сделал с огромным усилием. Каждый рисунок радужного стола выходит из хакера. Простыми словами это очень тяжело.
• Как и в случае с пунктом 1, если мы сделаем так, чтобы хакер вычислил таблицу радуги для каждого пользователя, тогда он стареет к тому моменту, когда узнает пароль. И если пользователь часто меняет пароль, тогда даже дети-хакеры станут старыми, когда узнают пароль.
• Ok. Поэтому для каждого пользователя используйте различную соль. Это позволяет хакерам использовать отдельную атаку, чтобы знать пароль каждого отдельного пользователя.
• Я вижу, что различные читатели отметили, что вместо того, чтобы стучать головой на каждого пользователя, большой хакер будет прилагать все усилия к учетной записи администратора, а затем он будет сделан:). Итак, в этом случае мы сделаем шаг вперед, а затем применим другой метод для вычисления хэша. Допустим, соль не совсем то, что хранится. Это может быть половина фактического хэша. Другая половина хранится где-то еще каким-то другим способом (вычисляется каким-то другим способом). Это всего лишь дополнительная мера безопасности. И мы знаем, что в настоящее время вычислительная мощность компьютеров растет. Поэтому этические люди знают, что самый быстрый суперкомпьютер в мире займет 1 год, чтобы взломать пароль администратора (просто пример). Поэтому они вынуждают политику, в которой говорится, что пароль администратора администрирования происходит каждые 3 месяца. к тому времени, когда хакер знает старый пароль, новый действует. Или сказать, что база данных скомпрометирована, тогда хорошие парни узнают об этом, когда хакер взломает пароль. И хорошие парни меняют вещи к тому времени (помните апгрейд алогоримов..sha1 sha2 и теперь sha3).....

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

Будьте осторожны....

Ответ 6

Если вы не храните соль, как вы проверите, был ли указан правильный пароль?