Какая нормализация Unicode (и другая обработка) подходит для паролей при хешировании?

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

Рекомендация №1. По возможности отклоняйте входные данные, не соответствующие ожидаемой кодировке. (Однако это может быть вне контроля приложения.)

Приложение 15 Unicode гарантирует стабильность нормализации, когда ввод содержит только назначенные символы:

11.1. Стабильность нормализованных форм

Для всех версий, даже до Unicode 4.1, применяется следующая политика:

Нормализованная строка гарантированно стабильна; то есть после нормализации строка нормализуется в соответствии со всеми будущими версиями Unicode.

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

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

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

Спецификация предупреждает:

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

Однако семантика и круговой обмен здесь не имеют значения.

Рекомендация №3: применяйте NFKC или NFKD перед хэшированием.