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

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

$ svn checkout http://svn.python.org/projects/peps/trunk

Если вы продолжаете получать сообщение об ошибке, возможно, это проблема вашего прокси-сервера. Я обнаружил, что не могу проверять интернет-проекты SVN на работе, потому что брандмауэр блокирует большинство HTTP-команд. Это позволяет только GET, POST и другие необходимые для просмотра.

45
задан Ned Batchelder 14 July 2010 в 13:12
поделиться

9 ответов

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

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

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

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

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

24
ответ дан 26 November 2019 в 21:08
поделиться

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

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

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

Поэтому, если вы хотите, чтобы ваша система была доступна, лучше убедиться, что пользователь сможет вводить свой пароль на всех типах устройств / операционных систем / сред,

38
ответ дан 26 November 2019 в 21:08
поделиться

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

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

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

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

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

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

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

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

t вписывается в него с помощью стандартного алгоритма Windows «Попытайтесь найти символ, который немного похож на него или, может быть, просто не имеет значения».

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

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

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

    t вписывается в него, используя стандартный алгоритм Windows «Попытайтесь найти символ, который немного похож на него или, может быть, просто не имеет значения» (Who Cares).

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

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

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

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

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

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

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

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

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

    20
    ответ дан 26 November 2019 в 21:08
    поделиться

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

    Однако я бы предположил, что, скажем, сайты с преимущественно японской, китайской или русской аудиторией будут использовать для паролей обычно используемые соответствующие символы, отличные от ASCII (Big5, EUC-KR, koi8 и т. д.). Может быть, вы сможете изучить, что они делают, чтобы справиться со старыми веб-клиентами, использующими что-либо не-Unicode.

    0
    ответ дан 26 November 2019 в 21:08
    поделиться

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

    0
    ответ дан 26 November 2019 в 21:08
    поделиться

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

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

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

    2
    ответ дан 26 November 2019 в 21:08
    поделиться

    Хорошая идея.

    ] Делает пароль более надежным, дает больше свободы пользователям. И это уже сделано в 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 , спасибо Джону).

    1
    ответ дан 26 November 2019 в 21:08
    поделиться

    Unicode - отстой, если вам нужно выполнять программное сопоставление. Знак «минус» и «тире» выглядят одинаково, но могут быть разными кодами. «n с забавной тильдой над ним» может быть одной буквой или диакритическим знаком и буквой.

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

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

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

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

    4
    ответ дан 26 November 2019 в 21:08
    поделиться

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

    При вводе пароля отображаются пули, скрывающие пароль.

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

    7
    ответ дан 26 November 2019 в 21:08
    поделиться
    Другие вопросы по тегам:

    Похожие вопросы: