О солях:
Соль — это общедоступные данные (если бы они были конфиденциальными, то их называли бы не «солью», а «ключом»). Соль должна быть известна для проверки пароля (поскольку она входит в хеш-функцию вместе с паролем), поэтому она хранится в виде открытого текста, как вы и намереваетесь сделать.
Суть соли в том, чтобы не дать злоумышленнику разделить затраты на атаку между экземплярами атаки. Часто возможно угадать выбранный пользователем пароль (у пользователей есть только человеческий мозг, и они редко хорошо запоминают сложные пароли). Соль гарантирует, что, по крайней мере, злоумышленнику придется заплатить полную цену за подбор пароля (т. е. «перебор» большого словаря возможных паролей) за каждый атакуемый пароль.
Соль работает хорошо, если она уникальна для каждого пароля. Обратите внимание, что уникальности для каждого пользователя недостаточно: иногда пользователи меняют свои пароли, и вы не хотите, чтобы одна и та же соль использовалась для следующего пароля (в противном случае будет доступен некоторый уровень распределения затрат для нападающий). Таким образом, вы хотите выбирать новую соль каждый раз при сохранении пароля, т. е. при создании учетной записи и при каждом изменении пароля.
Уникальность солей легко обеспечивается использованием достаточно больших случайных солей. 32-байтной соли для этого более чем достаточно: риск выбрать дважды одну и ту же соль (на худой конец) ничтожно мал.
Дополнительный уровень безопасности, помимо соления, заключается в том, чтобы сделать хеширование паролей «дорогим». Например, когда вы хешируете (соленый) пароль, вы фактически хэшируете конкатенацию в 10000 раз больше последовательности соль+пароль. Это делает проверку пароля в 10000 раз дороже, как для вас, так и для злоумышленника. Часто бывает так, что проверку законных паролей можно сделать вычислительно более сложной без заметного эффекта (даже если вы проверяете 100 пользовательских паролей в секунду, вы все равно можете выделить на это 100 мкс, и это займет только 1% вашего времени обработки), но усложнить задачу злоумышленнику в 10000 раз — хорошая идея.
О языках:
Основная проблема с паролями, отличными от ASCII, заключается в том, что некоторые глифы могут использовать несколько кодировок. Например, буква «é» может быть закодирована с помощью Unicode как одна кодовая точка (U+00E9 СТРОЧНАЯ ЛАТИНСКАЯ БУКВА E С ОСТРОЙ) или как две кодовые точки (U+0065 СТРОЧНАЯ ЛАТИНСКАЯ БУКВА E, за которой следует U+0301 КОМБИНИРОВАНИЕ). ОСТРЫЙ АКЦЕНТ). Обратите внимание, что в этом примере речь идет о довольно распространенном французском письме, не столь причудливом (с точки зрения компьютера), как китайское или корейское. Проблемы с кодировкой можно решить с помощью Форм нормализации Unicode, но это непростая задача программирования. Могут помочь некоторые среды программирования (например, в Java используйте java.text.Normalizer, который реализует UNF).
Кроме того, не-ASCII-пароли могут оказаться трудными для ввода пользователями, которые меняют клавиатуру, например. когда пользователь хочет использовать общий компьютер в отеле или аэропорту (в любом случае вводить конфиденциальные пароли в таких системах не очень хорошая идея).
Я бы порекомендовал попытаться принудительно использовать пароли только для ASCII, если это возможно, или в противном случае укусить пулю: выполнить UNF (с формой NFD), затем кодировку UTF-8. Полученная последовательность байтов — это то, что отправляется на этап хэширования.
person
Thomas Pornin
schedule
03.11.2010
