Запрет символов в пароле?

Question

Есть ли что-то особенное в отношении символов, которые должны быть разрешены/запрещены в пароле?

Я хранил пароль в db hashed/salted и использовал PDO для предотвращения инъекции. Что я делаю достаточно? Недавно я наткнулся на систему, которая запретила ряд персонажей, не помню их всех, но один был амперсандом &. Они делали это по причинам, связанным с внедрением базы данных, или что-то еще мне не хватает? Должны ли символы паролей ограничиваться определенным набором символов или нет необходимости?

Answer 1

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

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

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

Простой предел скорости в системе входа в систему (например, отказ в доступе в течение 15 минут после 3 неудачных попыток входа в систему) убирает грань с более грубой угрозы.

Не нужно соглашаться на 100% с этим, но я нашел эту провокационную статью по этому вопросу из Microsoft Research очень интересной. So Long, And No Thanks for the Externalities: The Rational Rejection of Security Advice by Users

Из реферата:

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

Answer 2

Почему вы хотите ограничить символы паролем? Вы все равно должны делать какие-то хэширования. Мои пароли часто содержат специальные символы, в том числе те, которые не включены в клавиатуру.

Если вам нужны ограничения, они должны только требовать, чтобы они были более сложными, а не less.

Answer 3

Единственное, что я запрещаю/разделяю пароли, - это пробел, нет причин для того, чтобы перебирать что-либо еще.

Answer 4

Когда я ввожу пароли, я обычно люблю писать длинные предложения, которые я могу вспомнить вместо р»% &/k1 или тому подобное.

Поэтому убедитесь, что позволит пользователям писать пароли длиннее 10signs. Меня всегда разочаровывает, когда я вынужден ввести короткий пароль со специальными символами вместо более длинного, который будет более запоминающимся и безопасным.

Answer 5

Я только запрещаю символы, которые не могут быть напечатаны на стандартной клавиатуре. Нет причин, по которым пользователь не может выбрать безопасный пароль с 26 прописными и строчными буквами, 10 цифрами и 20 символами.

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

Answer 6

Не связывайтесь с паролем пользователя.

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

В качестве примеров я пришел с такими глупыми правилами, как пароли, ограничиваясь 4 цифрами (!!!), только буквенные символы (az), а некоторые академические сайты молча усекают пароли до 10 символов при регистрации, а затем не работают вы пытались войти с длинным паролем.

Answer 7

Я наткнулся на этот вопрос, проведя некоторое исследование, и я думал, что должен внести свой вклад.

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

Возьмем, к примеру, буква ü (в нижнем регистре у с умляут):

• В расширенном формате ASCII, что символ 0x81.
• В ISO-8859-1 (очень распространенный в западных странах) это 0xFC.
• В UTF-8 ü имеет элемент кода U + 00FC, и, следовательно, может быть представлен в виде 0xC3BC
• В UTF-8 символ может быть также не нормируется, хотя. Таким образом, он может состоять из символа умлаута (только ¨) плюс u: результатом является другая другая последовательность байтов.

Во всех случаях над хешем для пароля будет отличаться, и логин завершится неудачно.

Возможное решение, позволяющее любому символу Юникода гарантировать, что вся страница использует UTF-8 повсюду и нормализует пароли (например, с режимом NFC) перед их хэшированием.
Однако в этот момент может быть проще просто запретить любой символ, который не является частью стандартной таблицы ASCII: байты 0x00-0x7F или (еще лучше, дескрипторы управления и другие не представимые плюс символы перевода строки) 0x20-0x7E.