Должен ли я поддерживать Unicode в паролях?
Я хотел бы разрешить своим пользователям использовать Unicode для своих паролей.
Однако я вижу, что многие сайты не поддерживают это (например, Gmail, Hotmail).
Поэтому мне интересно, есть ли какие-то технические проблемы или проблемы с юзабилити, которые я упускаю из виду.
Я думаю, что в любом случае это должно быть проблемой юзабилити, так как по умолчанию.NET принимает Unicode, и если Hotmail - новая Live-почта - построена на этом, я не понимаю, почему они ограничивают это.
Кто-нибудь сталкивался с подобными проблемами?
10 ответов
Я уверен, что нет никаких технических проблем, но, возможно, gmail и hotmail не поддерживают это специально. Этот вид веб-сайтов имеет широкую аудиторию и должен быть доступен везде.
Давайте представим, что у пользователя есть пароль на японском языке, но он находится в путешествии и идет в кибер-кафе, а поддержка японского языка отсутствует, и пользователь не сможет войти в систему.
Еще одна проблема - проанализировать сложность пароля. Не так сложно убедиться, что пользователь не набрал обычное слово на английском, а как на китайском / русском / тайском. Гораздо сложнее проанализировать сложность пароля, поскольку вы добавляете больше языков.
Поэтому, если вы хотите, чтобы ваша система была доступна, лучше убедиться, что пользователь сможет вводить свой пароль на всех типах устройств / ОС / сред, поэтому буквенно-цифровой пароль с наиболее распространенными символами (!<>"#$%& и т. д.) это хороший набор символов, доступных везде.
Как правило, я категорически за то, чтобы не ограничивать, какие символы разрешены в паролях. Однако помните, что вы должны сравнивать что-то с чем-то, что может быть паролем или хэшем. В первом случае вы должны убедиться, что сравнение выполняется правильно, что гораздо сложнее с Unicode, чем с одним ASCII; в последнем случае вам нужно будет убедиться, что вы хэшируете точно то же самое при каждом вводе. Формы нормализации могут помочь здесь или быть проклятием, в зависимости от того, кто их применяет.
Например, в приложении, над которым я работаю, я использую хэш вместо преобразования пароля UTF-8, который был предварительно нормализован, чтобы отсеять потенциальные проблемы с объединением символов и тому подобное.
Самая большая проблема, с которой могут столкнуться пользователи, заключается в том, что они не могут ввести его в некоторых местах, например, на другой раскладке клавиатуры. Это уже относится к одному из моих паролей, но до сих пор проблем не было. И в конце концов, это решение, которое пользователь должен принять при выборе своего пароля, а не то, которое приложение должно принимать от имени пользователя. Я сомневаюсь, что есть пользователи, которые с радостью используют произвольный Unicode в своих паролях и не думают о проблемах, которые могут возникнуть при использовании другой раскладки клавиатуры. (Однако, это может быть проблемой для веб-сервисов больше всего на свете.)
Однако есть случаи, когда Юникод справедливо запрещен. Одним из таких примеров является TrueCrypt, который принудительно использует раскладку клавиатуры США для паролей при загрузке (для шифрования полного тома). Там нет другой раскладки, и поэтому Unicode или любая другая раскладка клавиатуры только создает проблемы.
Однако это не объясняет, почему они запрещают Юникод в обычных паролях. Предупреждение может быть хорошим, но прямое запрещение неправильно в моих глазах.
Поэтому мне интересно, есть ли какие-то технические проблемы или проблемы с юзабилити, которые я упускаю из виду.
Существует техническая проблема с паролями, не относящимися к ASCII (и именами пользователей) с базовой аутентификацией HTTP. Насколько я знаю, сайты, которые вы упоминали, обычно не используют базовую аутентификацию, но это может быть похмелье от систем, которые используют.
Стандарт HTTP Basic Authentication определяет кодировку base64 username:password маркер. Это означает, что если у вас есть двоеточие в имени пользователя или пароле, результаты будут неоднозначными. Кроме того, base64-декодирование токена дает вам только байты, без указания того, как преобразовать эти байты в символы. И угадай что? Для этого разные браузеры используют разные кодировки.
Opera и Chrome используют UTF-8.
IE использует кодовую страницу по умолчанию в клиентской системе (которая, конечно, никогда не является UTF-8) и искажает символы, которые не вписываются в нее, используя стандарт Windows. Попробуйте найти символ, который выглядит немного похожим, или, может быть, просто нет (кто Забота) алгоритм.
Safari использует ISO-8859-1 и молча отказывается отправлять какой-либо токен авторизации, когда в имени пользователя или пароле есть символы, которые не подходят.
Mozilla берет младшие 8 бит кодовой точки (аналогично ISO-8859-1, но более битая). См. Ошибку 41489 для извилистых обсуждений без результата или прогресса.
Таким образом, если вы разрешите имена пользователей и пароли, отличные от ASCII, тогда процесс базовой аутентификации будет в лучшем случае сложным и непоследовательным, а пользователям будет интересно, почему он работает случайным образом или не работает, когда они используют разные компьютеры или браузеры.
Ограничьте пароли ASCII-символами.
При вводе пароля отображаются маркеры, чтобы скрыть пароль.
Но когда вы вводите японский и другие языки, вы должны пройти через метод ввода, преобразуя нажатия клавиш в нужные символы. Это требует, чтобы вы увидели, какие персонажи.
Unicode отстой, если вам нужно сделать программное сопоставление. "Знак минус" и "тире" выглядят одинаково, но могут быть отдельными кодами. "n со смешной тильдой над ним" может быть одной буквой или диакритическим знаком и буквой.
Если люди используют разные методы кодирования, их пароли могут не совпадать, даже если они выглядят одинаково. Смотри omg-ponies aka humanity = эпический провал.
Вы можете нормализовать, но что происходит, когда:
- правила нормализации меняются
- у вас есть несколько пользователей с диакритическими знаками в их пароле
- у вас есть несколько пользователей с комбинированными буквами в пароле
- пароли хешируются, поэтому вы не можете изменить пароли
Угадайте, что - вам нужно принудительно сбросить пароль для некоторых из ваших пользователей.
Я поддерживаю пароли Unicode во всех моих веб-приложениях. Если используется последний браузер, посетитель может использовать любой код в своих предпочтительных или собственных сценариях.
Для повышения безопасности я сохраняю соленый хеш, а не использую обратимое шифрование.
Важно правильно нормализовать и закодировать строку пароля перед добавлением последовательности байтов в хеш (я предпочитаю UTF-8 для независимой последовательности).
Отличная идея.
Усиливает пароль, дает больше свободы пользователям. И это уже сделано Windows (начиная как минимум с Win 2000), Active Directory и LDAP, Novell (начиная как минимум с 2004 года)
Некоторые клиенты хотят этого ( http://mailman.mit.edu/pipermail/kerberos/2008-July/013923.html), и даже существует стандарт того, как это сделать правильно ( http://tools.ietf.org/html/rfc4013).
С HTML 5, с возможностью отправлять своим пользователям шрифт, вы можете интегрировать визуальную клавиатуру в вашу систему, чтобы пользователи могли использовать ваш язык,
Подсказка: используйте шрифт Deja Vu и измените его с помощью FontForge, чтобы сделать его меньше, а затем с помощью визуальной клавиатуры javascript вы можете сделать это возможным;)
Посмотрите здесь, это проект, где я сделал трюк.
Я уверен, что многоязычные аналоги этих сайтов поддерживают Unicode. Похоже, проблема с требованиями пользователя, а не техническая проблема.
Я не был бы удивлен, если есть техническая проблема с сервером, не уверенным в кодировке, в которую клиент отправляет пароль.
Тем не менее, я бы предположил, что, скажем, сайты с преимущественно носителями японской, китайской или русской аудитории будут использовать обычно используемый соответствующий набор символов не ASCII (Big5, EUC-KR, koi8 и т. Д.) Для паролей. Может быть, вы можете исследовать, что они делают, чтобы справиться со старыми веб-клиентами, используя любой не-Unicode материал.