Должен ли я поддерживать Unicode в паролях?

Ответ 1

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

Представьте, что у пользователя есть пароль на японском языке, но он путешествует и идет в кибер-кафе, и японская поддержка не поддерживается, и пользователь не сможет войти в систему.

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

Таким образом, если вы хотите, чтобы ваша система была доступна, лучше убедиться, что пользователь сможет ввести свой пароль для всех типов устройств/ОС/сред, поэтому буквенно-цифровой пароль с наиболее распространенными символами (!<>"#$%& и т.д.) - это хороший набор символов, доступных везде.

Ответ 2

В общем, я категорически настаиваю на том, чтобы не ограничивать, какие символы допускаются в паролях. Однако помните, что вам нужно что-то сравнить с чем-то, что может быть паролем или хешем. В первом случае вы должны убедиться, что сравнение выполнено правильно, что намного сложнее с Unicode, чем с ASCII; в последнем случае вам нужно будет убедиться, что вы хешируете точно так же, когда он вводится. Формы нормализации могут помочь здесь или быть бичем, в зависимости от того, кто их применяет.

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

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

Однако существуют случаи, когда Unicode правильно запрещен. Одним из таких примеров является TrueCrypt, который заставляет использовать раскладку клавиатуры США для паролей загрузки (для полноразмерного шифрования). Там нет другого макета, поэтому Unicode или любая другая раскладка клавиатуры создают проблемы.

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

Ответ 3

Так что мне интересно, есть ли какая-то техническая или юзабилити-проблема, которую я пропускаю.

Существует техническая проблема с паролями без ASCII (и именами пользователей, если на то пошло) с базовой аутентификацией HTTP. Насколько я знаю, сайты, о которых вы упомянули, обычно не используют Basic Authentication, но это может быть похмелье от систем, которые делают.

Стандарт базовой аутентификации HTTP определяет токен username:password, основанный на base64. Это означает, что если у вас есть двоеточие в имени пользователя или пароле, результаты неоднозначны. Кроме того, base64-декодирование токена дает вам только байты, без указания способа преобразования этих байтов в символы. И угадай что? Для этого разные браузеры используют разные кодировки.

• Opera и Chrome используют UTF-8.

• IE использует кодовую страницу по умолчанию для клиентской системы (которая, конечно же, не UTF-8) и управляет символами, которые не вписываются в нее, используя стандарт Windows. Попробуйте найти символ, похожий на него, Или, может быть, просто не (кто заботится) алгоритм.

• Safari использует ISO-8859-1 и молча отказывается отправлять любой токен аутентификации вообще, когда имя пользователя или пароль имеют символы, которые не подходят.

• Mozilla принимает самые младшие 8 бит кодовой точки (аналогично ISO-8859-1, но больше не работает). См. ошибка 41489 для извилистого обсуждения без каких-либо результатов или прогресса.

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

Ответ 4

Нет. Ограничьте пароли символами ASCII.

При вводе пароля отображаются маски для скрытия пароля.

Но когда вы вводите японский и другие языки, вы должны пройти через метод ввода, преобразуя нажатия клавиш в нужные символы. Это требует, чтобы вы увидели, что представляют собой символы.

Ответ 5

Unicode отстой, если вам нужно выполнить программное сопоставление. Знаки "минус" и "тире" выглядят одинаково, но могут быть отдельными кодами. "n со смешной тильдой над ней" может быть одной буквой, диакритикой и буквой.

Если люди используют разные методы кодирования, их пароли могут не совпадать, хотя пароли выглядят одинаково. См. omg-ponies aka human = epic fail.

Вы можете нормализовать, но что происходит, когда:

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

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

Ответ 6

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

Для повышения безопасности я сохраняю засоленный хеш вместо использования обратимого шифрования.

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

Ответ 7

Отличная идея.

Усиливает пароль, дает больше свободы пользователям. И это уже сделано Windows (начиная как минимум с Win 2000), Active Directory и LDAP, Novell (начиная как минимум с 2004 года)

Некоторые клиенты хотят этого (http://mailman.mit.edu/pipermail/kerberos/2008-July/013923.html), и даже существует стандарт того, как это сделать правильно (https://tools.ietf.org/html/rfc8265 3, устарел http://tools.ietf.org/html/rfc4013, спасибо Джон).

Ответ 8

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

Ответ 9

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

Ответ 10

с HTML 5, с возможностью отправки вашим пользователям шрифта, вы можете интегрировать визуальную клавиатуру в свою систему, чтобы пользователи могли использовать ваш язык,

Подсказка: используйте шрифт Deja Vu и измените его, используя FontForge, чтобы вы могли сделать его меньше, а затем, используя визуальную javascript-клавиатуру, вы можете сделать это;)

Посмотрите здесь, это проект, в котором я сделал трюк.