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

Question

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

Однако, если подумать об этом, есть множество персонажей, которые я понятия не имею, как они повлияют на вещи. Иностранные символы, символы ASCII и т. Д., Чтобы назвать пару.

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

В любом случае, существуют ли стандартные рекомендации по длине, разрешенным символам и т. Д.?

Я не уверен, имеет ли это значение, но я буду использовать ASP.NET с C #

Answer 1

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

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

Answer 2

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

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

Answer 3

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

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

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

Answer 4

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

Answer 5

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

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

Answer 6

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

Answer 7

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

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

Answer 8

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

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

Answer 9

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

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

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