Мне просто интересно, почему на каком-то веб-сайте не разрешено ничего кроме буквы и цифр в поле пароля.
Есть ли причина безопасности или, возможно, это просто ограничение используемой базы данных? Спасибо за информацию.
Изменить: Похоже, что база данных Oracle не подтверждает прописные и строчные буквы? Это правда? Мне сказали, что через PM. Спасибо за информацию ребята, это действительно полезный материал.
Интересно, почему в этом вопросе осталось 3 голоса. Недостаточно jQuery и от руки?
Никакой причины вообще, кроме неаккуратного кодирования БД, где они разрешали бы обычный текст в БД или использовать (не переносные) функции БД для хеширования пароля и использования прямого оператора SQL. Это похоже на проверку простой строки.
Кроме того, с практической стороны, размещение специального персонажа на чужой или тесной клавиатуре является сложным и может быть более неприятным для пользователей, путешествующих (или в более современном случае альтернативного ввода, например, на экранной клавиатуре на смартфоне). Некоторые веб-сайты могут даже продвинуть систему дальше, предоставив собственную экранную клавиатуру для входа (с различным скремблированием).
Запрет специальных символов помогает QA и уменьшает разочарование пользователя от нескольких платформ.
И, наконец, с помощью ограниченного набора (считающегося безопасным) набора символов (это не только знаки препинания, но и больше символов на языке в Юникоде) разработчик также может избежать путаницы кодирования между браузером и серверным приложением (кодирование данных формы не является очень понятный в стандарте и может быть сложным в некоторых браузерах).
Они мертвы мозгами и боятся пунктуации в целом - и точки считаются пунктуацией. Это скорее случай "дружественного огня", чем точка, представляющая опасность. Даш тоже безвреден.
Одна из проблем - SQL Injection, конечно. Другая - компетенция рабочей силы по программированию.
Я работал в одном месте, которое хотело читать пароли по телефону (что было сделано с поддержкой). Поддержка людей не знала всех имен символов (хеш, удары, трубы, амперсанд/и, звездочка/звезда) и другие проблемы (которые вы оставили в скобках, вы имеете в виду, какую цитату и т.д.). Поэтому они не допустили никаких знаков препинания.
Непонятная причина (поддержка не должна знать мой пароль), но вы не просили только по веским причинам:)
Нет причин. Они просто некомпетентны. Любые проблемы с SQL-инъекцией или чем-либо еще являются неправильными. Это просто говорит вам, что они обеспокоены возможной инъекцией безопасности, потому что они не хешируют и не шифруют ваш пароль.
О верхнем/нижнем регистре: если вы храните пароль в виде обычного текста, это может быть проблемой. Я не уверен в Oracle, но SqlServer считает, что "Пароль" и "пароль" идентичны.
Если вы храните пароль как хэш, то корпус оригинала не является проблемой: пароль действует с учетом регистра.
OWASP довольно ясен по этому вопросу. Его первая часть руководства в OWASP Passwood Storage Cheat Sheet:
Не ограничивайте набор символов и задайте длинные максимальные длины для учетных данных. Некоторые организации ограничивают 1) типы специальных символов и 2) длину учетных данных, принятых системами, из-за их неспособности предотвратить SQL Injection, межсайтовый скриптинг, командные инъекции и другие формы инъекционных атак. Эти ограничения, но благими намерениями, облегчают некоторые простые атаки, такие как грубая сила.
Не допускайте использование коротких или длинных паролей и не применяйте набор символов или ограничения на запись в записи или хранения учетных данных. Продолжайте применять кодирование, экранирование, маскировку, прямое упущение и другие лучшие практики для устранения рисков инъекций.
Достаточная длина длинного пароля - 160. Очень длинные политики паролей могут привести к DOS при определенных обстоятельствах 1.
Не следует ли избегать всех возможных SQL-инъекций?
В целом, это плохая практика, чтобы просто ограничивать пароли числами и буквами. Тем не менее, это помогает защитить код от "инъекции кода", когда хакер передает некоторые инструкции в качестве части пароля для доступа к системе. Пароль, подобный "Apple", "Удалить * от пользователей", "может в конечном итоге нанести ущерб, если разработчик не позаботился о том, чтобы избежать ввода пользователя.
Другая проблема заключается в использовании специальных символов, которые могут вызвать конфликты в коде за сайтом. Или специальные символы, которые зависят от конкретного набора символов/кодировки, используемых в базе данных. Буквы типа ë, è, ï, î и ì являются специальными символами, которые можно использовать, если они разрешены. Но иногда они переводятся неправильно.
Другая проблема заключается в том, что некоторые люди, как правило, легко забывают свой пароль, что становится немного сложнее запомнить, если вам разрешено использовать специальные символы. Ограничивая пароль на меньшее количество комбинаций, вы также легко запоминаете пароли.
К сожалению, это также облегчает взламывание...
И часто это просто политика, установленная руководством некоторых компаний, которые просто не знают лучше. Ограничение может быть просто решением руководства, без логического объяснения, чем управление, требующее сохранения паролей таким образом...