Как обращаться с солями, которые не могут быть случайными?Детерминированная стратегия засолки

Question

Рассмотрим следующий сценарий:

• Пользователи вводят уникальные коды (например, подарочные карты) на веб-сайте.
• Код соответствует объекту в базе данных, который необходимо получить.
• Код является секретным и не может быть сохранен в виде простого текста.
• Вместо этого код будетхешироваться и храниться в базе данных.Алгоритм хеширования будет sha-512 или bcrypt в сочетании с некоторой стратегией посола.

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

Я хотел бы получить информацию о следующих идеях:пользователь ввел код, чтобы действовать как соль?

salt = sha2(code)
hashedCode = hash(code + salt)

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

salt = sha2(code + globalSecret)
hashedCode = hash(code + salt)

Спасибо!

Answer 1

Если ваши 16-значные буквенно-цифровые коды (0-9 аз. Аз.) Генерируются действительно случайным образом, они достаточно сильны, чтобы их можно было хэшировать и хранить без засоления, даже с быстрым алгоритмом хеширования, таким как SHA-256.

Вы можете повысить безопасность, используя ключ на стороне сервера, неважно, шифруете ли вы хэши или используете HMAC.Важно то, что злоумышленнику нужны дополнительные привилегии на сервере, чтобы получить ключ, прежде чем он сможет начать взлом (SQL-инъекция недостаточна).

Если коды более слабые (более короткие), вы также можете использоватьрастяжение ключа, чтобы увеличить необходимое время для грубой силы.Даже несколько миллисекунд для одного вычисления препятствуют атакам методом перебора, если коды не слишком короткие.Растяжение ключа может быть сделано независимо от посола.Лучше, конечно, использовать достаточно сильные коды.

Answer 2

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

Поиск секретов в проблеме с БД

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

Пользователь вводит код на передней панели.Затем ваше приложение извлекает запись базы данных.Затем пользователь вводит код вычеркивания на обороте.И вы можете сравнить этот код с кодом в вашей базе данных.

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

1234 5511 2121 1234 --- 12345511 - идентификатор записи, а 21211234 - секретный код.

---

Хеширование - неправильный подход

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

В вашем сценарии вы можете оказаться в состоянии, когдакто-то украдет вашу базу данных, а затем сможет угадать все коды.Ну, вот проблема с вашим решением.Если я знаю, что коды находятся в диапазоне от 1 до 100000000, то я могу пронумеровать от 1 до 100000000, вычислять хэш / bcrypt для каждого из них и восстанавливать все коды.Я могу сделать это за считанные минуты.Если вы не отправляете коды длиной 2 ^ 128 (которые я бы никогда не набрал), решение полностью ошибочно.

Конечно, именно поэтому они имеют солт-значение.Так что мне нужно перейти к каждому хэшу подарочного кода и просмотреть все 10000000 значений.Но это все еще пара часов работы, а не годы, которые вы бы хотели.Соль не решает проблему вообще.

---

Как тогда сделать это?

Если вы рискуете, когда кто-то крадет базу данных, а затем использует все подарочные коды дляукрасть деньги, происходит одна из двух вещей.Вы либо отменяете все коды (тогда группа людей, у которых есть подарочные карты, приходят в бешенство), либо вы защищаете коды.

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

giftcode_in_db = HMAC(<SECRETKEY>, giftcode_from_user)

Теперь, чтобы защитить все свои подарочные коды, вам просто нужно защитить секретный ключ.Используйте его только в памяти, и пусть оператор вводит его вручную или использует Hashicorp Vault для выполнения фактической операции HMAC.

Если кто-то украл вашу базу данных, ему также необходимо украсть секретный ключ.Если кто-то украл секретный ключ, ему также нужно украсть базу данных.