Чому певні сайти запобігають пробілам у паролях?

Це здається менш поширеним із новішими веб-сайтами, але багато веб-сайтів, у яких мені потрібен обліковий запис (наприклад, для оплати рахунків тощо), не дозволяють мені створити пароль із пробілами в ньому. Це лише ускладнює запам’ятовування , і я знаю, що немає баз даних або обмежень програмування пробілів у паролях, зашифрованих або (не дай бог) інакше. Чому тоді пробіл настільки дискримінований, коли мова заходить про реєстрацію на сайті?

Існує величезна кількість дурощів, коли справа стосується паролів на веб-сайтах.

• У деяких є чисто технічні причини (дійсні чи ні, це вже інше питання, але майже всі вони не є):

Ваш пароль повинен містити чотири символи та мати лише цифри.

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

• Інші пояснюються помилковими думками, що вони зроблять паролі більш безпечними :

Ваш пароль повинен починатися з великої літери і закінчуватися цифрою.

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

• Інші, нарешті, пояснюються тим, що паролі зберігаються в простому тексті , і існують певні неясності щодо того, як вони зберігаються, обробляються або витягуються, і немає часу на те, щоб перевірити їх одиницю.

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

або,

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

або,

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

У всіх трьох випадках розробник просто гарантував, що такі паролі будуть зберігатися правильно.

• У першому випадку, що, якщо éбуде перетворено %C3%A9надіслане? Або що робити, якщо база даних зберігатиметься éнеправильно?

• У другому випадку, що робити, якщо PHP (чому PHP?) Не може мати справу з unicode, і робить щось жахливе при отриманні такого пароля? Що робити, якщо <персонаж викликає неприємності? Що робити, якщо &символ трактується як роздільник у URL-адресі (якщо припустити, що чомусь пароль надсилається через GET замість POST)? Що робити, якщо 'інтерпретується база даних, тому що, здогадайтесь, ми не маємо уявлення, що таке інжекція SQL і як цього уникнути? Або що робити, якщо 'перетворюється на \'?

• У третьому випадку, що робити, якщо PHP (знову ж таки?) Обрізає пробіли в деяких випадках, а не в інших? Що робити, якщо адміністратори (у яких напрочуд доступ до паролів користувачів у простому тексті) втрачені, оскільки вони бачать лише одне пробіл, а користувач встановив три послідовних пробіли ?

У всіх трьох випадках ці двозначності легко вирішуються за допомогою тестування , особливо тестування одиниць. Але у величезній кількості проектів взагалі немає тестування і часу на тестування (але все ж достатньо часу для налагодження пізніше).

Це означає, що чи розробник намагається подумати про можливі наслідки дозволу пробілів , або символів Unicode, або просто будь-якого символу поза ASCII 48..57 ∪ 65..90 ∪ 97..122 (цифри, малі літери, великі літери) , найпростіший спосіб, коли тестування неможливо - це просто заборонити їх .

На мою думку, це єдина причина заборонити пробіли. Янніс Різос дав ще одну причину, пов’язану з UX. Будучи правдоподібною причиною в теорії, це практично не працює на практиці: веб-сайти, створені людьми, які насправді дбають про UX, не фіксують дурних правил пароля. Натомість веб-сайти, де пробіл фактично заборонений, здебільшого роблять люди, які ніколи не чули про UX . Це особливо актуально, оскільки заборона будь-якого символу насправді дратує з точки зору UX, оскільки будь-яке обмеження, пов’язане з паролем, включаючи корисні, як мінімальна кількість символів.

Відповідь - Історія

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

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

Чи мають бути обмеження в нових системах зараз ? Я би сподівався, що ні - набагато менше причин зараз

IMHO, абсолютно нерозумно будь-який сайт / додаток, який використовує сучасні хешування та / або засолювання для зберігання паролів, щоб не допускати пробілів у паролях. Але деякі застарілі системи (читайте про це десь) все ще передають паролі в простому тексті - тому не допускаючи пробілів, можливо, є сенс. Також деякі програми можуть "знімати" всі введені рядки, які вони отримують. Отже, пароль, починаючи або закінчуючи пробілом, не буде корисним (звичайно, це було надто надумано, але ви можете уявити, що не може статися майже з будь-ким, хто приходить зі своїм власним сайтом). Немає нічого "поганого" у допущенні пробілів у паролях - як ви зазначаєте, БД не заборонять хеші чи версії простого тексту.

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

Це робиться з тієї ж причини, що на багатьох сайтах забороняються дефіси, апострофи чи літери, що не належать до ASCII, навіть якщо це дуже поширена практика навіть у США, і це вимагає більше роботи, щоб заборонити цих символів, ніж просто дозволяти їх.

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

Це тому, що багатьом розробникам, мабуть, не вистачає здорового глузду, або, принаймні, дуже обмежена уява, коли розглядаються можливі введення та сценарії користувачів. Невеликий відсоток з них може відпрацьовувати неправдиву інформацію (що виключення не алфавітно-цифрових символів якимось чином є звичайною практикою, або що алгоритм хешування або метод зберігання не може обробляти пробіли або спеціальні символи). Інші можуть просто лінуватися - вони турбуються про проблеми з комірками, тому вони просто обмежують введення мінімальним простором символів. І тоді можуть бути ті, хто здійснює надмірне підтвердження введення / санітарію через параноїю через нерозуміння реальних загроз.