Следует ли разрешать Юникод в именах пользователей? - PullRequest
48 голосов
/ 12 августа 2010

Почему большинство (все?) Веб-сайтов поддерживают только имена пользователей в ASCII? Существуют ли какие-либо соображения безопасности, если администратор решает начать принимать имена пользователей Unicode?

Ответы [ 8 ]

58 голосов
/ 12 августа 2010

Гомоглифические атаки.Пользователь 'cat' и 'сat' - это разные строки Юникода, хотя они выглядят одинаково.Первая буква во втором 'сat' - это русская буква 'с', если быть точным, "CYRILLIC SMALL LETTER ES".Система не может с легкостью определить, что вы подделываете имя другого пользователя - для компьютера другие прозвища.

Редактировать: предотвращение смешанных сценариев не решает проблему.Например, «сосо» чисто кириллический и может использоваться для подмены ascii «кокос».

Кроме того, переопределение слева направо (и друзей.) Оставьте их безанизированными, и они испортят всю вашу страницу.

6 голосов
/ 23 августа 2010

Хотя вообще сомнительно, почему для идентификации пользователя всегда должно быть имя пользователя, а не просто «пароль», я думаю, что нет причин запрещать имена пользователей в юникоде.быть утвержденным как независимый от языка: он должен обрабатывать нажатия клавиш независимо от настроек клавиатуры пользователя.Это означает, что «שלום» и «akuo» будут одним и тем же паролем.Это важно, потому что пользователь часто не видит символы пароля, которые он вводит, и они сильно раздражаются, если включен CAPSLOCK.

6 голосов
/ 12 августа 2010

HTTP аутентификация? При отправке имени пользователя (и / или пароля) по юникоду по существующим протоколам могут возникнуть некоторые проблемы. Один случай, с которым я столкнулся раньше, - это обычная аутентификация. Не существует четко определенного способа обработки этих имен пользователей и паролей в юникоде в основных заголовках аутентификации.

4 голосов
/ 12 августа 2010

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

Рассмотрим основной случай нарушения чувствительности регистра: на турецком языкеимена пользователей "Id1" и "id1" различны (на турецком языке есть два разных значения Is, одно с точкой и одно без, в результате чего 2 заглавные буквы и 2 строчные буквы, которые не соответствуют одинаковой заглавной буквыправила как английский).Таким образом, хотя любой турецкий человек может ввести свое имя на своем родном языке, программа не будет обращаться с его именем так, как они ожидают, - вместо этого она подвергнется странному преобразованию в мутантский английский.

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

3 голосов
/ 13 августа 2010

Ваше наблюдение не всегда верно. И выбор ASCII в значительной степени зависит от человеческого фактора, а не от технических проблем или проблем безопасности.

В большинстве случаев это просто для простоты программирования. Программист никогда не знает, что все программное обеспечение, библиотеки, утилиты на веб-сайте сломаются или нет с некоторыми символами. Зачем рисковать разработкой сайта, пока ASCII работает хорошо? Кроме того, некоторые упакованные веб-программы будут препятствовать использованию Unicode в имени пользователя. Это способствует тому, что многие веб-сайты поддерживают только имена пользователей в ASCII.

Теоретически, все текущее программное обеспечение может хорошо обрабатывать 8-битные данные. В настоящее время нет проблем с хранением или передачей. Даже если некоторых протоколов нет, они могут транслироваться в UTF-7 или с другими схемами преобразования.

Есть некоторые проблемы с Unicode. Это больше на стороне обработки данных. Это может быть отображение, шрифты, готовность программного обеспечения и программных библиотек для символов, отличных от BMP, сопоставление, сравнение, методы ввода, указания по написанию. Администраторы могут быть недостаточно осведомлены, чтобы справиться с ними. В зависимости от характера веб-сайта это может быть проблемой, но в основном это не так.

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

Однако, нередко китайские имена пользователей используются на китайском веб-сайте. Это не всегда может быть в ASCII. Как и другие культуры и языки. Некоторые глобальные проекты принимают почти все виды символов Unicode. Википедия является примером.

2 голосов
/ 12 августа 2010

Обычный ASCII - редкость, я бы сказал.Часто просто никто не думает об этом, так как в Западной Европе достаточно латинского 1 и для США.Некоторые базы данных делают различия между текстом в устаревших наборах символов и Unicode (varchar против nvarchar), или для других баз данных должен быть установлен специальный набор символов.

Особенно в США многие люди даже не замечаютэтого ASCII будет недостаточно.Некоторые пытаются найти оправдания с помощью »Пользователи должны ввести его« или аналогичные, которые в большинстве своем являются поддельными, однако.

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

0 голосов
/ 13 августа 2010

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

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

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

0 голосов
/ 12 августа 2010

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

...