Чи слід накладати на паролі максимальну довжину?

162

Я можу зрозуміти, що накладення мінімальної довжини паролів має багато сенсу (щоб врятувати користувачів від себе), але мій банк має вимогу, щоб паролі були між 6 та 8 символами, і я почав цікавитися ...

Хіба це не полегшило б грубі сили нападу? (Погано)
Чи означає це, що мій пароль зберігається незашифрованим? (Погано)

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

security encryption passwords

— нікф
джерело

16

Майже напевно існує політика "три удари, і ти перебуваєш поза", яка виключає загрозу грубої атаки.

— Стю Томпсон

23

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

— mparaz

7

Я не думаю, що відповідь суто ІТ. Мінімальний розмір (6) та максимальна межа спроб "ймовірно" усувають дикі здогадки. Я здогадуюсь, що максимальний розмір (8) - це обмеження кількості дзвінків (а отже, і вартості) підтримки на підтримку "На жаль, я забуваю свій код" або "Я набираю код на швидку" або "Я вводячи помилково один символ" і т. д. Крім того, на папері, на якій ви пишете пароль, якщо не можете його запам'ятати ..

— телефонуйте мені Стів

17

В університеті, який зарахований, є шалено дурні правила пароля: лише 8 символів, принаймні 1 номер, але не на початку чи в кінці пароля, потрібні символи з більш ніж 2 верхніх рядків клавіатури тощо. Зрештою. вони полегшують жорстоке посилення, маючи ці правила -.-. Я усвідомлюю, що ти не такий дурний, але будь ласка, не роби таких дурних правил! (Просто довелося вийти з моєї системи :))

— cwap

17

@call Ну , якщо ви накладаєте максимальну довжину з цієї причини , то ви отримаєте «Я забув свій пароль» дзвінки від мене , бо мого сайту унікальних паролів все давно, і обмежуючи мене 12 символів вірного способу гарантувати , я буду не пам’ятати цього.

— Роман Старков

193

Паролі хешовані до 32, 40, 128, незалежно від довжини. Єдина причина мінімальної довжини - це запобігання легкому відгадуванню паролів. Немає мети для максимальної довжини.

Обов'язковий XKCD, що пояснює, чому ви робите користувачеві послугу, якщо ви нав'язуєте максимальну довжину:

— еповольф
джерело

6

Можливо, банк може вибрати обмеження пароля, оскільки в банкоматах ви не можете вводити більше, скажімо, 8 символів.

— Андре Шалелла

11

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

— nickf

39

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

— jevon

14

Зітхайте, навіть на PayPal "правильний штапельний акумулятор для коней" на 8 символів перевищує їх < максимальну довжину > максимальну довжину ... шевелюра

— Роман Старков

3

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

— Vicky Chijwani

75

Максимальна довжина, вказана в полі пароля, повинна читатися як ПОПЕРЕДЖЕННЯ БЕЗПЕКИ . Будь-який розумний, захищений безпекою користувач повинен вважати найгірше і очікувати, що цей сайт зберігає ваш пароль буквально (тобто не хеширується, як пояснив epochwolf).

У цьому випадку:

Якщо це можливо, не використовуйте цей сайт, як чума. Вони, очевидно, нічого не знають про безпеку.
Якщо ви справді повинні користуватися сайтом, переконайтеся, що ваш пароль унікальний - на відміну від будь-якого пароля, який ви використовуєте в інших місцях.

Якщо ви розробляєте веб-сайт, який приймає паролі, не встановлюйте дурних лімітів паролів, якщо ви не хочете, щоб їх міняли тією ж щіткою.

[Внутрішньо, звичайно, ваш код може вважати лише перші 256/1024 / 2k / 4k / (що завгодно) байтами як "значущими", щоб уникнути розчавлення паролів мамонта.]

— тардат
джерело

17

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

— Роман Старков

3

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

— benc

5

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

— tardate

1

Будь ласка, докладно. Ця відповідь є простим твердженням.

— kleinfreund

1

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

— emorris

58

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

Відправник може спробувати надати вам такий довгий пароль, що призведе до відмови у наданні послуг іншим людям. Наприклад, якщо пароль становить 1 Гб даних, і ви витрачаєте весь час на його прийняття, поки не закінчиться пам'ять. Тепер припустимо, що ця людина надсилає вам цей пароль стільки разів, скільки ви готові прийняти. Якщо ви не будете обережні щодо інших параметрів, то це може призвести до DoS-атаки.

Встановлення верхньої межі на щось на зразок 256 символів здається занадто щедрим сучасним стандартам.

— Джейсон Дагіт
джерело

35

Ви все одно можете надсилати 1 Гб даних з максимальним обмеженням. Програмне забезпечення, що робить обмеження, майже завжди відстає від веб-сервера.

— epochwolf

6

Ви все ще можете скинути всі, крім перших 256 годин, перш ніж робити щось обчислювально інтенсивно. Запуск шаш-хешу на 1 Гб даних забирає набагато більше часу, ніж той самий хеш на 256 символів.

— rcreswick

2

@Eyal: все, що трапляється на стороні клієнта веб-програми, по суті не є довіреною; таким чином, хеш стає еквівалентом пароля, що робить це вправою марності. (веб-браузер, ймовірно, не сприймає введення тексту 1 Гб, а користувацький клієнт може надіслати рядок 1 Гб у полі форми "цездійснено пропуск слова")

— Пісквор вийшов із будинку

4

@Piskvor: Але жодним чином не можна запобігти рядок 1 ГБ. Користувач завжди може запросити example.com/?password=abcabcabcabc ... і зробити його запит настільки великим, наскільки він хоче. Стандартні DoS.

— Eyal

4

@Piskvor та Eyal, на щастя, Apache та IIS (і, мабуть, інші зрілі сервери) обмежують довжину полів, що передаються через URL-адреси: boutell.com/newfaq/misc/urllength.html

— sampablokuper

21

По-перше, не припускайте, що в банках працюють хороші фахівці з ІТ-безпеки. Дуже багато .

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

— Спарр
джерело

Домовились! Подивіться на те, що рядок банківського доступу до Інтернету щодо доступу до Інтернету в безпеці за останні кілька років ...

— Стю Томпсон,

6

Я вже використовую інший пароль на кожному веб-сайті через схему, яка дозволяє мені запам’ятати їх усіх, але всі вони досить довгі. Єдині веб-сайти, паролі яких я записую на клейкі нотатки, - це ті, які накладають морочні обмеження на максимальну довжину і, таким чином, відштовхують мене від мого улюбленого, але унікального пароля ...

— Роман Старков

@romkyns Я вважаю, що ваша схема не використовує символи? Колись у мене була така схема, яка створювала короткі жорсткі паролі, але мені довелося відмовитися від неї, коли 10-20% сайтів, які я використовував, забороняли загальні спеціальні символи.

— Спарр

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

— Роман Старков

1

@romkyns інші проблеми з такими схемами: сайти, які діляться паролями. Якщо ваша схема є чимось на зразок nameofwebsitefO0 (googlefO0 yahoofO0 тощо), то як ви пам'ятаєте, що ви повинні використовувати "yahoofO0" на flickr.com або stackoverflowfO0 на askubuntu.com? сайти, термін дії яких закінчується паролями. то вам потрібно розширити схему, щоб включити частину, яка може змінюватися. але це не вдається, якщо правило закінчення перевіряє наявність підрядів.

— Спарр

13

Встановлення максимальної довжини пароля менше 128 символів тепер перешкоджає шпаргалці автентифікації OWASP

https://www.owasp.org/index.php/Authentication_Cheat_Sheet

Посилаючись на весь абзац:

Більш довгі паролі забезпечують більшу комбінацію символів і, отже, ускладнюють здогадник.

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

Максимальна довжина пароля не повинна встановлюватися занадто низькою, оскільки це не дозволить користувачам створювати парольні фрази. Типова максимальна довжина - 128 символів. Заборонені фрази менше 20 символів зазвичай вважаються слабкими, якщо вони складаються лише з малих латинських символів. Кожен персонаж рахує !!

Переконайтеся, що кожен символ, який вводиться користувач, фактично включений у пароль. Ми бачили системи, які усікають пароль на довжину, меншу, ніж надала користувач (наприклад, усічений на 15 символів, коли він вводив 20). Зазвичай це обробляється шляхом встановлення довжини ВСІХ полів введення паролем точно такої ж довжини, як пароль максимальної довжини. Це особливо важливо, якщо максимальна довжина пароля коротка, як 20-30 символів.

— кравець
джерело

11

Це джерело не перешкоджає обмеженню максимальної довжини пароля, воно відбиває низькі (менше 128 символів) максимальні обмеження довжини пароля.

— Матвій

9

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

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

— mbac32768
джерело

1

Хоча це зрозуміло, застарілим системам іноді доводиться диктувати дизайн. Наскільки це можливо, вони НЕ повинні впливати на це. Останнє, що потрібно в новій системі, - це політика безпеки, розроблена до того, як сучасні напади на безпеку були навіть поширеними. Або ще гірше, новіше програмне забезпечення, але в першу чергу неправильно розроблене. Існуюча корпоративна система може використовувати HTTP, але це не виправдання для використання SSL у новій системі чи розширенні. Крім того, політика щодо паролів не повинна залишатися вразливою лише тому, що ОСТАННІ хлопці зробили це неправильно. А якщо зберігати, краще було б ВЕЛИЧЕЗНО вивчити витрати та вигоди.

— Katastic Voyage

6

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

Потім знову потрібно настроїти сервери для автоматичного відключення обробників запитів, які займають занадто багато часу. Тому я сумніваюся, що це буде великою проблемою.

— AardvarkSoup
джерело

4

Я думаю, ви дуже праві в обох пунктах. Якщо вони зберігають хешовані паролі, як слід, то довжина пароля взагалі не впливає на їх схему БД. Наявність відкритої довжини пароля включає ще одну змінну, за яку зловмисник повинен відповідати.

Важко побачити привід для обмеження довжини пароля, окрім поганого дизайну.

— Лукас Оман
джерело

3

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

— DrStalker
джерело

1

Має бути максимальна довжина вводу, так, але це точно не повинно бути <64. Максимальна довжина 8 або 12 просто смішна.

— Дан Бешард

2

Ігноруйте людей, які говорять, щоб не перевіряти довгі паролі. Овасп буквально говорить, що 128 символів має бути достатньо. Просто, щоб дати достатньо місця для дихання, ви можете дати трохи більше сказати 300, 250, 500, якщо вам здається, що це подобається.

https://www.owasp.org/index.php/Authentication_Cheat_Sheet#Password_Length

Довжина пароля Більш довгі паролі забезпечують більшу комбінацію символів і, отже, ускладнюють здогадник.

...

Максимальна довжина пароля не повинна встановлюватися занадто низькою, оскільки це не дозволить користувачам створювати парольні фрази. Типова максимальна довжина - 128 символів . Заборонені фрази менше 20 символів зазвичай вважаються слабкими, якщо вони складаються лише з малих латинських символів.

— CommonSenseCode
джерело

Не стосується дискусії. Питання полягає в тому, чи є якась користь від обмеження довжини, а не те, чи достатньо 128?

— вікі

1

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

Цілком ймовірно, що банківська система перекриває старішу систему, тому вони змогли дозволити певний простір для пароля.

— LizB
джерело

9

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

— Стю Томпсон,

8

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

— Роман Старков

1

Мій банк теж робить це. Він використовував для дозволу будь-якого пароля, і я мав 20 символів. Одного разу я змінив його, і ось, це дало мені максимум 8, і вирізав не буквено-цифрові символи, які були в моєму старому паролі. Не мали для мене жодного сенсу.

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

Рішення розумної картки не подобається мені. У мене вже занадто багато карток, як це є ... Мені не потрібна ще одна хитрість.

— Вінсент Макнаб
джерело

Вони вирізали важливий простір ключів, який подовжується на час жорстоких атак, коли (і я маю на увазі КОЛИ) їхню базу даних хешей викрадено (припускаючи, що вони навіть солять / хешують / розтягують, що я впевнений, що їх немає). Час змінити банки.

— Кріс Гомес

1

Якщо ви приймаєте пароль довільного розміру, тоді передбачається, що він стає усіченим до довжини завіси з міркувань продуктивності, перш ніж він буде хеширован. Проблема з усіченням полягає в тому, що з часом з підвищенням продуктивності вашого сервера ви не можете легко збільшити довжину перед усіченням, оскільки його хеш очевидно був би іншим. Звичайно, у вас може бути перехідний період, коли обидві довжини хешируються і перевіряються, але для цього використовується більше ресурсів.

— Користувач
джерело

1

Намагайтеся не накладати жодних обмежень, якщо це не потрібно. Попереджуйте: це може бути і знадобиться у багатьох різних випадках. Одним із таких причин є взаємодія зі застарілими системами. Переконайтеся, що ви добре перевірили випадок дуже довгих паролів (чи може ваша система мати справу з паролями довжиною 10 Мб?). Ви можете зіткнутися з проблемами відмови в сервісі (DoS), оскільки ключові функції відхилення (KDF), які ви будете використовувати (зазвичай PBKDF2, bcrypt, scrypt), займуть багато часу та ресурсів. Приклад із реального життя: http://arstechnica.com/security/2013/09/long-passwords-are-good-but-too-much-length-can-be-bad-for-security/

— Марек Пучальський
джерело

0

Чи повинна бути максимальна довжина? Ця цікава тема в ІТ в тому, що довші паролі, як правило, важче запам'ятати, а отже, швидше за все їх записують (ВЕЛИКИЙ ні-ні з зрозумілих причин). Більш довгі паролі також, як правило, більше забуваються, що, хоча не обов'язково загрожує безпеці, може призвести до адміністративних клопотів, втрати продуктивності тощо. Адміністратори, які вважають, що ці проблеми нагальні, швидше за все, накладуть паролі на максимальну тривалість.

Я особисто вірю в це конкретне питання, у кожного користувача своє. Якщо ви думаєте, що можете запам'ятати пароль із 40 символів, тоді вам все більше сили!

Сказавши, що паролі швидко перетворюються на застарілий режим захисту, смарт-карти та автентифікація сертифікатів виявляються дуже важкими для неможливих грубими силами, як ви заявили, - це проблема, і лише приватний ключ повинен зберігатися на сервері з приватним натискайте на Вашій картці / комп’ютері постійно.

— tekiegreg
джерело

Люди можуть легко запам’ятати улюблену лірику пісні, вірш із Біблії чи іншу приказку. Вони дуже довгі порівняно з типовим паролем. Я тільки тестував один і ввійшов у 79 символів! (Зрозуміло, можливість помилки зростає, чим довше є пароль. Ще гірше, коли на веб-сайті STUPID не відображається останній символ, який ви ввели у вікні пароля.)

— Katastic Voyage

0

Більш довгі паролі чи фразові фрази важче зламати просто на основі довжини та їх легше запам’ятати, ніж вимагати складного пароля.

Напевно, найкраще їхати на досить великій (10+) мінімальній довжині, обмежуючи довжину марною.

— benPearce
джерело

0

Спадкові системи (вже згадувані) або взаємодія між системами постачальника можуть потребувати обмеження 8 символів. Це також може бути помилкова спроба врятувати користувачів від себе. Обмеження його таким чином призведе до занадто великої кількості паролів pssw0rd1, pssw0rd2 тощо.

— Чак
джерело

0

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

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

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

— Кріс Дж
джерело

-4

Всього 8 знаків довгих паролів звучать просто неправильно. Якщо має бути обмеження, то принаймні 20 знаків - це краща ідея.

— користувач17000
джерело

3

Але в цьому справа - взагалі не повинно бути межі.

— Люк Стівенсон

-4

Я думаю, що єдиний ліміт, який слід застосувати, - це такий, як обмеження в 2000 літер, або щось інше шалено високе, але тільки для обмеження розміру бази даних, якщо це проблема

— Джош Хант
джерело

9

Паролі слід хешувати ... І розмір бази даних не буде проблемою, це пароль хешований.

— epochwolf

4

@epochwolf - Я можу придумати одну з причин, чому паролі не слід завжди хешировать (тому що я сам це відкрив сьогодні): пароль, який потрібно надіслати третій стороні від імені користувача, не може зберігатися як хеш значення. [Наприклад, додаток, який повинен зберігати облікові дані для надсилання електронних листів через зовнішній домен.]

— Кенні Евітт