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

Question

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

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

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

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

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

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

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

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

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

Answer 1

Нет особых причин беспокоиться о атаках со вставкой SQL, если только вы на самом деле не вставляете пароль в базу данных в виде обычного текста (Опасно, Уилл Робертсон, опасно!), и даже тогда, если вы параматериализируете запрос, это не будет проблемой.Вы должны разрешить [a-zA-Z0-9] плюс некоторый набор специальных символов.Вероятно, единственным символом, который следует ограничить, является '<' который вызовет предупреждение о проверке ASP.net .Существует ряд интересных инструментов для проверки сложности пароля на стороне клиента.Мне нравится этот.Это обеспечивает некоторую мгновенную обратную связь с пользователем по мере ввода текста.

Answer 2

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

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

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

Answer 3

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

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