Каковы наилучшие правила выбора символов, которые следует использовать в пароле?

В паролях обычно разрешены любые печатные символы ASCII без пробелов (от 33 до 126 включительно). Многие специалисты по безопасности (и комментаторы SO) советуют использовать кодовую фразу вместо пароля. , поэтому вам нужно будет разрешить пробелы. Аргумент состоит в том, что из-за их длины и из-за того, что фразы отсутствуют в словаре, парольные фразы труднее взломать, чем пароли. (Парольную фразу также легче запомнить, поэтому законному пользователю не нужно записывать ее на стикере прямо на мониторе.)

Некоторые надежные генераторы паролей используют хеш, поэтому я бы установил очень высокий предел длины ( 512 или 1024) просто для включения. Генераторы паролей сегодня часто выдают строки из 32-128 символов, но кто знает, какие хеши будут использоваться в ближайшие несколько лет.

Символы, отличные от ASCII, безусловно, усложняют ввод пароля на ограниченных устройствах (мобильные телефоны, консоли и т. Д.), Но обычно это возможно. Возможно, если пользователь хочет это сделать, вы должны ему позволить. Достаточно просто сделать разумную и последовательную вещь - например, закодировать в UTF-8 перед хешированием. Вы столкнетесь с трудностями только в том случае, если какое-то устройство ввода отправит символы в виде композиции (например, е + острый акцент вместо «е острый») - но я подозреваю, что в реальной жизни этого не произойдет. (Вы можете разложить все самостоятельно, но в крайнем случае это будет сложно.)

Однако я бы ограничился печатными символами. Добавление вкладок, каналов форм и т. Д. В пароль действительно вызывает проблемы.

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

Короткий ответ: позвольте столько, сколько поддерживает система, которую она может поддерживать. В настоящее время действительно нет оправдания, чтобы не использовать полную поддержку Unicode для ввода текста, включая пароли. Я не думаю, что вам нужно беспокоиться о проблемах с символами, если они обрабатываются буквально (но я не профессионал в этой области - остерегайтесь внедрения sql).

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

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

По сути, следует разрешить большинство символов класса Unicode. Пропускайте, однако, управляющие символы (например, 0–31 помимо пробела), отметку порядка байтов (0xfffe и oxfeff). Кроме того, вы хотите сначала канонизировать представление, чтобы избавиться от проблем, вызванных разными представлениями. Вы можете выдавать предупреждения для символов, которые кажутся слишком сложными для ввода, но пользователи сами будут защищаться от этого.

Помните: когда вы храните пароли, все пароли должны быть зашифрованы односторонним алгоритмом, например md5 of sha1. Поскольку эти алгоритмы всегда выдают шестнадцатеричные числа, вам не нужно беспокоиться о SQL-инъекциях или чем-то подобном.

Итак, если вы можете использовать md5 или sha1 для персонажа, его следует принять.

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

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

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

(Конечно, даже если вы разрешите все, 99% пользователей все равно будут использовать имя своего питомца в качестве пароля ...)

В конце концов вам, возможно, придется распечатать открытый пароль в электронном письме с подтверждением, отправленном вашим пользователям.

PS: Можно также рассмотреть проблемы с кодировкой в ​​электронном письме, если это не стандартный ascii (например, японские символы), возможно, что пользователь не получит электронное письмо в правильном формате или просто не сможет прочитать его в другой системе из-за шрифтов. не устанавливается.

Все это весит в диапазоне «печатаемых» символов ascii.