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

Question

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

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

Я искал руководство и передовую практику на этом и до сих пор не имел большой радости. last post on this SO question затрагивает проблему, но на самом деле не дает никаких указаний.

Answer 1

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

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

Более подробная информации о китайских методах ввода можно увидеть на Wikipedia - Chinese input methods for computers

Answer 2

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

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

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

Answer 3

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

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

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

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