Есть ли причина, по которой некоторые сайты не разрешают использовать пароли? - PullRequest
23 голосов
/ 18 октября 2010

Мне было просто интересно, почему некоторые веб-сайты не допускают ничего, кроме букв и цифр в поле пароля.

Существует ли причина безопасности или, возможно, это просто ограничение используемой БД?Спасибо за информацию.

Редактировать: Похоже, что база данных Oracle не поддерживает прописные и строчные буквы?Это правда?Мне сказали это через личку.Спасибо за информацию, ребята, это действительно полезные вещи.

Интересно, почему этот вопрос имеет 3 голоса, чтобы закрыть.Не хватает jQuery и кругов от руки?

Ответы [ 8 ]

21 голосов
/ 18 октября 2010

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

Одной из проблем является SQL-инъекция , конечно. Другой - компетенция программистов.

11 голосов
/ 18 октября 2010

Я работал в одном месте, где хотел иметь возможность читать пароли по телефону (так была оказана поддержка).Сотрудники службы поддержки не знали всех названий символов (хэш, взрыв, труба, амперсанд / и, звездочка / звезда) и других вопросов (какую левую скобку вы подразумеваете, какую цитату и т. Д.)Таким образом, они не допускали пунктуации.

Не веская причина (служба поддержки не должна знать мой пароль), но вы спрашивали не только по веским причинам:)

7 голосов
/ 18 октября 2010

Нет никаких причин, за исключением неаккуратного кодирования БД, где они допускают простой текст в БД или используют (не переносимые) функции БД для хеширования пароля и использования прямого оператора SQL. Это похоже на проверку простой строки.

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

Запрещение специальных символов помогает QA и уменьшает разочарование многоплатформенного пользователя.

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

4 голосов
/ 18 октября 2010

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

1 голос
/ 09 декабря 2015

OWASP довольно ясно по этому вопросу.Его первое руководство в шпаргалке OWASP Passwood Storage :

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

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

Разумная длина длинного пароля составляет 160. Очень длинные политики паролей могут привести к DOS при определенных обстоятельствах 1 .

1 голос
/ 18 октября 2010

О верхнем / нижнем регистре: если вы храните пароль в виде простого текста, это может быть проблемой. Я не уверен насчет Oracle, но SqlServer считает, что «Password» и «passWORD» идентичны.

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

0 голосов
/ 18 октября 2010

В общем, плохая практика - просто ограничивать пароли цифрами и буквами.Тем не менее, это помогает защитить код от «внедрения кода», когда хакер передает некоторые инструкции как часть пароля, чтобы получить доступ к системе.Пароль типа `Apple;" Delete * from users; "" может в конечном итоге нанести ущерб, если разработчик не позаботится о том, чтобы избежать пользовательского ввода.Другая проблема - использование специальных символов, которые могут вызвать конфликты в коде сайта.Или специальные символы, которые зависят от конкретного набора символов / кодировки, которые используются в базе данных.Буквы, такие как ë, è, ï, î и ì являются специальными символами, которые можно использовать, если это разрешено.Но иногда они переводятся неправильно.Другая проблема заключается в том, что некоторые люди, как правило, легко забывают свой пароль, который становится немного сложнее запомнить, если вам разрешено использовать специальные символы.Ограничивая пароль меньшим количеством комбинаций, вы также облегчаете запоминание паролей.К сожалению, это также облегчает их взлом ...И часто это просто политика, установленная руководством определенных компаний, которые просто не знают лучше.Ограничение может быть просто решением руководства, без логического объяснения, кроме того, что руководство хотело бы хранить пароли таким образом ...

0 голосов
/ 18 октября 2010

Разве это не позволяет избежать всех возможных SQL-инъекций ?

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...