Почему некоторые сайты запрещают использование пробелов в паролях?

16

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

security login privacy

— Ян Хантер
источник

Возможно, некоторые сайты используют Single Sign On, если предположить, что для единого входа требуются непустые пароли (хотя и не уверен)!

— NoChance

1

Что действительно пугает меня, так это то, что сайты специально запрещают единственную цитату. Какую возможную причину вы могли бы иметь, кроме как включить "insert into USERS (..., password) values (..., '" + $POST['password'] + "');" : -S

— Кристиан Клаузер

Должны были пойти в охрану, а не программисты. Это, вероятно, уже существует там, хотя.

— Дэн МакГрат,

20

Существует огромное количество глупостей, когда дело доходит до паролей на веб-сайтах.

У некоторых есть чисто технические причины (действительные или нет, это другой вопрос, но почти все из них нет):

Ваш пароль должен быть длиной четыре символа и иметь только цифры.

(Ограничив пароль диапазоном 0001 .. 9999, вы можете просто сохранить их как число в виде открытого текста в базе данных)

Другие объясняются ошибочными мыслями о том, что они сделают пароли более безопасными :

Ваш пароль должен начинаться с заглавной буквы и заканчиваться цифрой.

(Делая это, разработчик или менеджер предполагал, что это фактически заставит пользователей выбирать безопасный пароль, в то время как правило «Ваш пароль должен содержать не менее 6 символов и содержать как минимум одну заглавную букву, строчную букву и цифра "волшебным образом не сможет этого сделать)

Другие, наконец, объясняются тем фактом, что пароли хранятся в виде открытого текста , и есть некоторые неясности относительно того, как они хранятся, обрабатываются или извлекаются, и нет времени для их модульного тестирования.

Ваш пароль содержит недопустимый символ é.

или,

Ваш пароль y$₯46¥*A'xD<7&฿=ᴙcN&sF5_Ở!dсодержит недопустимые символы. Используйте символы только латинского алфавита и цифры.

или,

Ваш пароль не может содержать пробельные символы.

Во всех трех случаях разработчик был просто уверен, что пароли, подобные этому, будут храниться правильно.

В первом случае, что, если éбудет преобразовано %C3%A9при отправке? Или что, если база данных будет храниться éнеправильно?
Во втором случае, что если PHP (почему PHP?) Не может работать с юникодом и делает что-то ужасное при получении такого пароля? Что, если <персонаж вызывает проблемы? Что если &символ интерпретируется как разделитель в URL-адресе (при условии, что по какой-то причине пароль отправляется через GET вместо POST)? Что если 'интерпретируется базой данных, потому что, угадайте, что, мы понятия не имеем, что такое SQL-инъекция и как ее избежать? Или что, если 'превращается в \'?
В третьем случае, что если PHP (снова?) Обрезает пробелы в одних случаях, а не в других? Что делать, если администраторы (которые неожиданно имеют доступ к паролям пользователей в виде открытого текста) теряются, потому что они видят только один пробел, в то время как пользователь установил три последовательных пробела ?

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

Это означает, что разработчик пытается подумать о возможных последствиях использования пробелов , символов Юникода или просто любого символа вне ASCII 48..57 ∪ 65..90 ∪ 97..122 (цифры, строчные буквы, прописные буквы) , самый простой способ, когда это невозможно, это просто запретить их .

На мой взгляд, это единственная причина запрета пробелов. Яннис Ризос привел еще одну причину, связанную с UX. Хотя это и является правдоподобной причиной в теории, на практике это совсем не работает: веб-сайты, созданные людьми, которые действительно заботятся о UX, не устанавливают глупые правила паролей. Вместо этого веб-сайты, где пробелы фактически запрещены, в большинстве случаев создаются людьми, которые никогда не слышали о UX . Это особенно верно, поскольку запрет любого символа действительно раздражает с точки зрения UX, как любое ограничение, связанное с паролем, включая полезные, как минимальное количество символов.

— Арсений Мурзенко
источник

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

— Lèse Majesté

1

Я согласен с большинством прочитанного, но мне очень тяжело переварить утверждение «самый простой способ, когда тестирование невозможно ...». Тестирование не возможно ??? Любой, кто соглашается на проект, где это происходит: глупость эффективно максимизируется ... Да, я знаю, что это происходит: - |

— Томас

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

— Арсений Мурзенко

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

— суперкат

3

Ответ - История

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

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

Должны ли быть ограничения в новых системах сейчас ? Я надеюсь, что нет - гораздо меньше причин сейчас

— Murph
источник

Вы говорите, что были технологические ограничения с пробелами в паролях, которых не было раньше? Какую роль в этом сыграло хранилище?

— Ян Хантер

1

Я предполагаю, что технологические ограничения и менее сложные внешние ограничения (и, возможно, использование «отделки») означают, что люди думают по-разному о том, что будет уместно и допустимо. Вы можете установить ограничения на пароли, чтобы обеспечить их запоминаемость, поскольку их сброс сложнее. Вы не можете зашифровать их, потому что просто добраться до места, где вы можете их прочитать, (в то время) относительно трудно (и в любом случае системы недоступны из внешнего мира). Разные времена, совершенно разные мыслительные процессы, оставившие в наследство

— Мерф

2

ИМХО, это совершенно глупо для любого сайта / приложения, которое использует современное хеширование и / или солтинг для хранения паролей, чтобы не допустить пробелов в паролях. Но некоторые унаследованные системы (где-то об этом читают) все еще передают пароли в виде открытого текста, поэтому недопущение пробелов может иметь смысл. Кроме того, некоторые приложения могут «обрезать» все входные строки, которые они получают. Таким образом, пароль, начинающийся или заканчивающийся пробелом, не будет хорошим (конечно, это было слишком надуманным, но вы можете представить, что не может случиться с почти любым, кто придумывает свой собственный сайт). Нет ничего «плохого» в разрешении пробелов в паролях - как вы заметили, БД не будут запрещать хэши или незашифрованные версии.

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

— Яти Сагаде
источник

1

Я предпочитаю убирать начальные / конечные пробелы из паролей, потому что они, как правило, вызывают проблемы, но это не причина запрещать их - они просто будут удалены как при настройке, так и при тестировании, без проблем.

— Лорен Печтел

И что именно "проблемы"? Я подчеркивал в ответе, что пробелы ДОЛЖНЫ БЫТЬ разрешены. «Они будут лишены как настройки, так и тестирования». Какой смысл тогда? затем «1 4m 1337» и «1 4am 1337» оба хэшируют одно и то же значение (фактически, в теории существует бесконечное количество возможностей).

— Яти Сагаде

What's the point then?Минус в том, что пароль имеет меньшую энтропию, чем предполагал пользователь. А некоторые системы по умолчанию обрезают переменные GET / POST, (маловероятное) изменение этого поведения приведет к более серьезным проблемам.

— Яннис

@Yati Sagade: Я НЕ говорю о зачистке внутренних пространств. Я говорю о ведущих и конечных пробелах - люди не понимают, что пробел существует, и это вызывает сбои входа в систему. Аналогично, если вы видите пароль, который заглавными буквами переворачивается в нижний регистр, возможно, это кто-то, кто не понимал, что заглавные буквы включены.

— Лорен Печтел

-1

Это сделано по той же причине, по которой многие сайты не допускают дефисы, апострофы или не-ASCII буквы в именах, даже если это очень распространенная практика даже в пределах США, и для их запрета требуется больше работы, чем просто их.

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

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

— Lèse Majesté
источник

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

— Lèse Majesté