Юникод в логинах (и паролях)?

Question

После просмотра этого я понял, что у меня все еще есть несколько вопросов по этой теме.

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

Хотя по этому вопросу я, по общему признанию, не понимаю, почему администраторам, похоже, нравится применять правило «вы можете использовать только алфавит, цифры и пробелы».Может ли что-то еще быть недостатком безопасности или сломать что-то, о чем я не знаю (даже в ASCII)?Насколько я видел в мои дни кодирования, нет абсолютно никакой причины, по которой любому персонажу запрещается находиться в имени пользователя.

Answer 1

Если ваше приложение правильно обрабатывает ввод Unicode, я бы, конечно, разрешил не-ASCII-символы в именах пользователей и паролях с несколькими оговорками:

1. Если вы используете HTTP Basic Authentication,вы не можете должным образом поддерживать не-ASCII-символы в именах пользователей и паролях, потому что процесс передачи этих данных включает в себя этап кодирования в байты в base64, с которым в настоящее время браузеры не соглашаются:

   • Safari использует ISO-8859-1 и прерывается, если присутствуют любые символы, отличные от 8859-1;
   • Mozilla использует младший байт каждого символа, закодированного в UTF-16 единиц кода (аналогично ISO-8859-1 для этих символов);
   • Использование Opera и Chrome UTF-8
   • IE использует кодовую страницу ANSI в системе, в которой он установлен, что можетбыть чем угодно, но не ISO-8859-1 или UTF-8.Символы, которые не соответствуют кодировке, произвольным образом искажаются.

2. Если вы используете файлы cookie, вы должны убедиться, что любые символы Юникода каким-либо образом закодированы (например, URL-кодировка),так как повторная попытка отправки не-ASCII-символов дает совершенно разные результаты в разных браузерах.

"вы можете использовать только алфавит, цифры и пробелы"

У вас есть пробелы?Роскошь!

Answer 2

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

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

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

Answer 3

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

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

Разве это не так, как это делается на Facebook?

Answer 4

Часто это именно те символы, которые могут использоваться для внедрения вредоносного кода в вашу программу.Например, SQL-инъекция (кавычки, тире и т. Д.), XSS / CSRF (кавычки, фигурные скобки и т. Д.) Или даже инъекция языка программирования, когда eval() используется в другом месте вашего кода..

Эти символы обычно не причиняют вреда, когда вы, как разработчик, должным образом очищаете контролируемый пользователем ввод / вывод, т. Е. Все, что приходит с HTTP-запросом;Заголовки, параметры и тело.Например, параметризованные запросы или использование mysql_real_escape_string() при встраивании их в запрос SQL для предотвращения SQL-инъекций и htmlspecialchars() при встраивании их в HTML для предотвращения XSS.Но я могу представить, что администраторы не доверяют всем разработчикам, поэтому они добавляют эти ограничения.

См. Также:

• OWASP на PHP: 5 лучших уязвимостей

Answer 5

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

Например, файловые системы в Mac OS X обеспечивают единообразное представление символов Unicode, поэтому два разных имени файла Ą ('A with ogonek') и A + ̨ (латинский A, за которым следует 'объединения ogonek') обратитесь к тому же файлу.

Точно так же можно получить недопустимых последовательностей байтов UTF-8, где 1-байтовые кодовые точки кодируются с использованием нескольких байтов (так называемые слишком длинные последовательности). Если вы нормализуете или отклоняете ввод UTF-8 перед обработкой, это будет безопасно, но, например, если вы используете Unicode-невежественный язык программирования и Unicode-based базу данных, эти два будут видеть разные входные данные.

Итак, чтобы избежать этого:

• Вы должны отфильтровать ввод UTF-8 как можно раньше. Отклонить недействительные / слишком длинные последовательности.

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

Answer 6

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

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