i18n - Правила интернационализации и сложности паролей - PullRequest
Новая
       27

i18n - Правила интернационализации и сложности паролей

0 голосов
/ 12 июня 2009

В настоящее время я работаю над интернационализацией продукта, и возникла проблема. Проблема связана с требованиями к сложности пароля для стран с нелатинскими языками и сложными наборами символов.

Приложение использует членство в aspnet для управления пользователями и паролями, хотя это может быть совсем другой проблемой. В настоящее время наше приложение имеет настройки и код для размещения символов A-Z, 0–9 и специальных символов, из которых состоят пароли, но для них, скорее всего, потребуется расширение, чтобы справиться с другими культурами.

Я искал руководство и лучшую практику по этому вопросу, и пока не испытывал особой радости. Последнее сообщение по этому вопросу SO затрагивает проблему, но не дает никаких указаний.

Ответы [ 3 ]

1 голос
/ 14 июня 2009

Многое зависит от того, насколько безопасным должен быть доступ. Для обеспечения высокой безопасности парольный подход не очень практичен, и может быть лучше использовать биометрический (отпечаток пальца?) Или двухфакторный (SKey?) Подход, особенно в сочетании с цифровым PIN-кодом.

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

  • Многие языки не различают прописные и строчные буквы
  • Некоторые языки кодируют символы в два, три или четыре байта
  • Нет смысла вводить цифры или знаки препинания в паролях для культур с большим количеством идеограмм (таких как упрощенный китайский)
  • Ведение словарей для большого количества языков может быть непрактичным

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

0 голосов
/ 24 июня 2009

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

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

Более подробную информацию о китайских методах ввода можно найти в Wikipedia - Китайские методы ввода для компьютеров

0 голосов
/ 12 июня 2009

Зависит от того, что вы хотите применить. Проверка словаря и распознавание образов должны работать в любой кодировке и на любом языке. Если вы хотите применить популярные, но произвольные правила «сочетание прописных, строчных и числовых значений», то да, вам, вероятно, нужно найти A) библиотеку или API, которые могут определять регистр и цифры для любого языка, или B) создавать глупо большая база данных для отображения этой информации самостоятельно.

Однако такие правила сложности - это хак. Глупые люди БУДУТ создавать глупые пароли, независимо от того, какие правила сложности вы произвольно применяете. Передовой опыт в области безопасности паролей заключается в том, что пользователь должен выбрать пароль, который не так легко угадать, как это может быть, поэтому словарь проверяет (не забудьте добавить все слова на странице создания пароля и все слова, связанные с паролем запись, приложение или его окружение, а также вся доступная информация, относящаяся к пользователю, например, дата рождения и девичья фамилия) и сопоставление с образцом (abc123).

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

...