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

Question

Я прочитал много вопросов по SO по этому поводу, но многие ответы противоречат друг другу, или я не понимаю.

Вы всегда должны хранить пароль в виде хэша, а не в виде простого текста,Но следует ли хранить соль (уникальную для каждого пользователя) рядом с хешированным паролем + соль в базе данных.Это не кажется мне очень умным, так как никто не может получить доступ к базе данных, поищите, скажем, учетную запись с именем Admin или что-то еще, а затем определите пароль от этого?

Answer 1

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

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

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

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

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

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

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

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

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

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

Answer 2

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

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

Answer 3

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

Answer 4

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

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

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

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

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

Берегите себя ...

Answer 5

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

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

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

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

Answer 6

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