Мне нужна “случайная соль” однажды на пароль или только однажды для каждой базы данных?
В дополнение к моему предыдущему вопросу о соленых паролях в PHP/MySQL у меня есть другой вопрос относительно солей.
То, когда кто-то говорит, "используют случайную соль" для пред/добавлять к паролю, делает это означает:
- При создании помех 1 раз случайным образом генерировал строку символов, или
- При создании строки символов, которая изменяется наугад каждый раз, создается пароль?
Если соль случайна для каждого пользователя и сохраненная наряду с хешированным паролем, как исходная соль когда-либо получается назад для проверки?
4 ответа
Новая соль должна генерироваться случайным образом для каждого пользователя и, как минимум, каждый раз, когда они меняют свой пароль. Не полагайтесь, например, только на поваренную соль, так как это в первую очередь лишает смысла использование соли.
Использование уникальной соли для каждого пользователя означает, что если два пользователя имеют одинаковый пароль, они не получат одинаковый результирующий хэш. Это также означает, что атака методом перебора должна быть проведена против каждого пользователя индивидуально, а не иметь возможность предварительно вычислить радужную таблицу для сайта.
Затем вы сохраняете результат хеширования соли и пароля в базе данных хэш (соль + пароль) вместе с солью для каждого пользователя. Вы можете хранить их в отдельных столбцах или все в одном столбце (разделенных некоторым символом, не используемым в хэшах, например ; ). Пока вы можете получить и то, и другое, все будет в порядке.
Однако, если ваша база данных скомпрометирована либо из-за того, что кто-то получил локальный доступ, либо из-за атак с использованием SQL-инъекций, тогда будут доступны как соль, так и окончательный хэш, что означает, что атака грубой силы на пароли пользователей будет тривиальной. Для борьбы с этим, как предлагает Ладья , вы также можете использовать секретный ключ сайта, хранящийся в файле локально, в качестве другого входа вашего метода хеширования, чтобы злоумышленник также должен был знать это для проведения эффективной атаки. . Это означает, что ваша БД должна быть скомпрометирована, И злоумышленнику потребуется доступ к локальным файлам. Таким образом, используя хэш (хэш (соль + секрет) + пароль) и т. Д.
В то время как в большинстве алгоритмов вы стремитесь сделать работу как можно быстрее, для хеширования паролей вы хотите замедлить его, это называется Усиление ключа (или иногда растягивание ключа). Если для возврата вашей хэш-функции требуется 0,00001 секунды, кто-то может попробовать перебор 100000 паролей в секунду, пока не найдет совпадение. Если вашей хэш-функции требуется 1 секунда, чтобы выдать результат, это не имеет большого значения, если кто-то входит в ваше приложение, но для взлома пароля это более серьезное дело, поскольку каждая попытка теперь будет занимать 1 секунду, чтобы получить Это означает, что проверка каждого пароля методом перебора паролей займет в 100000 раз больше времени, чем при использовании вашей исходной хеш-функции.
Чтобы сделать вашу хеш-функцию медленнее, вам просто нужно запустить ее несколько раз. Например, вы можете выполнить new_hash = salt + password + previous_hash 100 000 раз. Возможно, вам придется изменить количество итераций на большее значение, если это будет слишком быстро. Если вы хотите иметь возможность изменить значение позже, обязательно сохраните количество итераций с записью пользователя, чтобы вы не повлияли на какие-либо ранее сохраненные пароли.
Ваша пользовательская запись должна теперь иметь поле, отформатированное примерно так: " $ " (или как отдельные поля, если хотите).
Когда пользователь вводит свой пароль, вы можете получить соль и количество итераций из БД и секрет всего сайта из локального файла и проверить, что, когда вы запускаете такое же количество итераций с солью и паролем, результирующий хэш соответствует тому, что вы сохранили.
Если пользователь меняет свой пароль, вы должны сгенерировать новую соль.
Используемый вами метод хеширования не имеет значения (но алгоритм хеширования имеет значение *). Выше я предложил хэш (хэш (соль + секрет) + пароль) , но в равной степени это может быть хеш (хеш (соль) + хеш (секрет) + хеш (пароль)) . Используемый вами метод не влияет на эффективность вашего хранилища паролей, один на самом деле не более безопасен, чем другой. Использование метода хеширования пароля и соли для обеспечения безопасности называется безопасностью через неясность , и ее следует избегать.
* Вы не должны использовать MD5 или SHA-1, поскольку они считаются небезопасными. Вместо этого используйте семейство SHA-2 (SHA256, SHA512 и т. Д.). ( Ссылка )
Динамическое изменение соли гораздо более безопасно, чем статическая соль.
Также сделайте соли уникальными для каждого пользователя, а не одной глобальной солью. Например, меняйте их каждый раз, когда пользователь входит в систему.
Присоединение соли к концу пароля с последующим хэшированием - это нормально, но это легко угадываемая формула. Лучше всего придумать свою собственную, т.е. переплести соль и пароль для создания новой строки, а затем хэшировать, поскольку md5(пароль + соль) по-прежнему уязвима для атаки по словарю.
Соль должна храниться вместе с хэшем, чтобы проверка была возможна. Лучшей практикой будет использование другой соли при каждом создании или изменении пароля.
Вторая альтернатива является правильной.
Традиционно соль хранится вместе с хэшированным паролем, но не шифруется (обычно с предварительным добавлением, например, в паролях unix)
Обновление: в большинстве новых Unix-систем используется этот метод.