Это кажется менее распространенным на новых сайтах, но многие сайты, на которых мне нужна учетная запись (например, для оплаты счетов и т. Д.), Не позволяют мне создать пароль с пробелами в нем. Это только усложняет процесс запоминания , и я не знаю никаких ограничений в базе данных или программировании на пробелы в паролях, в зашифрованном виде или (небеса запрещены) в противном случае. Тогда почему пробел так часто дискриминируется, когда дело доходит до регистрации на сайте?
16
"insert into USERS (..., password) values (..., '" + $POST['password'] + "');": -SОтветы:
Существует огромное количество глупостей, когда дело доходит до паролей на веб-сайтах.
(Ограничив пароль диапазоном 0001 .. 9999, вы можете просто сохранить их как число в виде открытого текста в базе данных)
(Делая это, разработчик или менеджер предполагал, что это фактически заставит пользователей выбирать безопасный пароль, в то время как правило «Ваш пароль должен содержать не менее 6 символов и содержать как минимум одну заглавную букву, строчную букву и цифра "волшебным образом не сможет этого сделать)
или,
или,
Во всех трех случаях разработчик был просто уверен, что пароли, подобные этому, будут храниться правильно.
В первом случае, что, если
éбудет преобразовано%C3%A9при отправке? Или что, если база данных будет хранитьсяéнеправильно?Во втором случае, что если PHP (почему PHP?) Не может работать с юникодом и делает что-то ужасное при получении такого пароля? Что, если
<персонаж вызывает проблемы? Что если&символ интерпретируется как разделитель в URL-адресе (при условии, что по какой-то причине пароль отправляется через GET вместо POST)? Что если'интерпретируется базой данных, потому что, угадайте, что, мы понятия не имеем, что такое SQL-инъекция и как ее избежать? Или что, если'превращается в\'?В третьем случае, что если PHP (снова?) Обрезает пробелы в одних случаях, а не в других? Что делать, если администраторы (которые неожиданно имеют доступ к паролям пользователей в виде открытого текста) теряются, потому что они видят только один пробел, в то время как пользователь установил три последовательных пробела ?
Во всех трех случаях эти неоднозначности легко решаются путем тестирования , особенно модульного тестирования. Но в огромном количестве проектов вообще нет тестирования и нет времени на тестирование (но все равно остается много времени для отладки позже).
Это означает, что разработчик пытается подумать о возможных последствиях использования пробелов , символов Юникода или просто любого символа вне ASCII 48..57 ∪ 65..90 ∪ 97..122 (цифры, строчные буквы, прописные буквы) , самый простой способ, когда это невозможно, это просто запретить их .
На мой взгляд, это единственная причина запрета пробелов. Яннис Ризос привел еще одну причину, связанную с UX. Хотя это и является правдоподобной причиной в теории, на практике это совсем не работает: веб-сайты, созданные людьми, которые действительно заботятся о UX, не устанавливают глупые правила паролей. Вместо этого веб-сайты, где пробелы фактически запрещены, в большинстве случаев создаются людьми, которые никогда не слышали о UX . Это особенно верно, поскольку запрет любого символа действительно раздражает с точки зрения UX, как любое ограничение, связанное с паролем, включая полезные, как минимальное количество символов.
источник
Ответ - История
Кажется, мы забываем, что во многом это основано на том времени, когда хранилище не было эффективно свободно (на диске или в памяти), когда наша способность управлять всеми этими вещами была несколько меньше, чем сейчас, и в равной степени способность автоматизированных систем. попытка взломать то же самое было также несколько меньше.
Есть много споров о паролях, основанных на том, что мы знаем сейчас и что мы можем сделать сейчас, но простой факт заключается в том, что мы часто имеем дело с комбинацией устаревшего мышления и устаревших систем.
Должны ли быть ограничения в новых системах сейчас ? Я надеюсь, что нет - гораздо меньше причин сейчас
источник
ИМХО, это совершенно глупо для любого сайта / приложения, которое использует современное хеширование и / или солтинг для хранения паролей, чтобы не допустить пробелов в паролях. Но некоторые унаследованные системы (где-то об этом читают) все еще передают пароли в виде открытого текста, поэтому недопущение пробелов может иметь смысл. Кроме того, некоторые приложения могут «обрезать» все входные строки, которые они получают. Таким образом, пароль, начинающийся или заканчивающийся пробелом, не будет хорошим (конечно, это было слишком надуманным, но вы можете представить, что не может случиться с почти любым, кто придумывает свой собственный сайт). Нет ничего «плохого» в разрешении пробелов в паролях - как вы заметили, БД не будут запрещать хэши или незашифрованные версии.
На самом деле большинство моих друзей по Windows не знают, что они могут использовать пробелы в своих паролях - поэтому, возможно, согласно ответу Тима Медоры, владельцы сайтов не хотят рисковать с ламами (простите, что), или, возможно, некоторые из них имеют заблуждения и / или не знают о преимуществах, которые могут дать пространства.
источник
What's the point then?Минус в том, что пароль имеет меньшую энтропию, чем предполагал пользователь. А некоторые системы по умолчанию обрезают переменные GET / POST, (маловероятное) изменение этого поведения приведет к более серьезным проблемам.Это сделано по той же причине, по которой многие сайты не допускают дефисы, апострофы или не-ASCII буквы в именах, даже если это очень распространенная практика даже в пределах США, и для их запрета требуется больше работы, чем просто их.
Это также делается по той же причине, по которой фильтры на многих сайтах не позволяют использовать такие слова, как «дерзкий», «замедляющий» или даже «накапливать» (хотя многие распространенные расовые оскорбления совершенно нормальны).
Это потому, что многим разработчикам явно не хватает здравого смысла или, по крайней мере, они имеют очень ограниченное воображение при рассмотрении возможных пользовательских входов и сценариев. Небольшой процент из них может быть обработкой ложной информации (исключение не алфавитно-цифровых символов является стандартной практикой или что алгоритм хеширования или метод хранения не может обрабатывать пробелы или специальные символы). Другие могут просто быть ленивыми - они беспокоятся о проблемах с кодировкой, поэтому они просто ограничивают ввод минимальным символьным пространством. И затем могут быть те, кто выполняет чрезмерно усердную проверку / санитарию ввода из-за паранойи из-за непонимания реальных угроз.
источник