Ограничение набора символов пароля пользователя - PullRequest
Новая
       7

Ограничение набора символов пароля пользователя

1 голос
/ 28 ноября 2009

Работа в системе входа в систему - точка, где клиент выбирает свой пароль для доступа к сайту.

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

Однако в случае с паролем я буду хэшировать его с соленым SHA-512 для вставки, что в любом случае вызывает несколько вопросов:

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

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

  • Существуют ли какие-либо символы / строки, которые необходимо отклонить - все равно они получат собственную защиту ASP.NET?

  • Возможно, немного более субъективно, но, учитывая, что это хеш SHA-512 - есть ли смысл ограничивать максимальную длину пароля, которую пользователь может выбрать (в пределах разумных параметров), предполагая, что пароль значительный размер / сложность может вызвать предупреждение, чтобы подтвердить, что они хотят установить его.

Спасибо за вашу помощь.

РЕДАКТИРОВАТЬ: Это веб-приложение ASP.NET, которое обращается к базе данных MSSQL2008 с помощью ADO.NET (не LINQ / EF).

Ответы [ 3 ]

3 голосов
/ 28 ноября 2009

С точки зрения не английского языка - не должно быть никаких ограничений на пароль.

Например, зачем ограничивать говорящего на японском языке набором символов US-ASCII? И почему говорящий на французском языке не должен использовать акцентированные символы?

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

1 голос
/ 29 ноября 2009

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

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

1 голос
/ 28 ноября 2009

Нет особых оснований беспокоиться о атаках вставки SQL, если вы фактически не вставляете пароль в базу данных в виде простого текста (Danger, Will Robertson, Danger!) И даже тогда, если вы параметризуете запрос, это не будет вопрос. Вы должны разрешить [a-zA-Z0-9] плюс некоторый набор специальных символов. Вероятно, единственный символ, который нужно ограничить - это «<», который вызовет предупреждение проверки ASP.net. Существует множество интересных инструментов для проверки сложности пароля на стороне клиента. Мне нравится <a href="http://view.jquery.com/trunk/plugins/validate.password/demo/" rel="nofollow noreferrer"> этот . Он обеспечивает мгновенную обратную связь с пользователем, когда он печатает.

...