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

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

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

8
mysql passwords php security

7 ответов

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

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

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

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

не обязательно соглашаться на 100%, но я нашел эту провокационную статью по теме из Microsoft Research очень интересной. так долго, и Нет спасибо за внешние эффекты: рациональное отклонение рекомендаций по безопасности пользователями

из аннотации:

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

10

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

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

3

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

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

2

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

2

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

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

0

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

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

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

0

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

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

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

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

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

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

0