Цитати про неприйнятність глобально унікального пароля

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

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

[EDIT]
Дякую за всі ваші відповіді, але я вже розумію проблеми із запропонованим підходом / вимогою, і навіть можу пояснити їх клієнтові, але клієнт не прийме їх, звідси мій запит на незалежні та / або авторитетні джерела .

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

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

Будь-які вказівки на незалежні та / або авторитетні джерела, чому це погана ідея, все ще вдячно отримані ...
[/ EDIT]

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

Поряд із цим, імена користувачів набагато простіше здогадатися (і якщо є форум, ви можете просто знайти багато імен користувачів там), і ви натякаєте на способи користувача зламати веб-сайт.

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

EDIT: Не близький до авторського, але, можливо, корисний після того, як ви поясните їм, що означає WTF: http://thedailywtf.com/Articles/Really_Unique_Passwords.aspx

Найкраща практика перешкоджає виконанню вимоги:

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

Ще одна редакція: До! Далекий огляд легко - ви все ще можете перевірити унікальність, оскільки (звичайно) у вас є сіль ... просто застреліть мене зараз ... звичайно, вам не потрібно згадувати цю деталь клієнту.

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

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

Гаразд, моя відповідь спочатку почалася з:

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

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

Застосування неповторних паролів витокує інформацію

Як? Оскільки кожного разу, коли зловмисник намагається створити нового користувача простим паролем, ваша система відповідає "Ні, не можу мати цей пароль", зломщик каже: "Гуді, це для списку".

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

Ресурси, що описують хороші та погані політики управління паролями

Прочитайте цю статтю експерта з питань безпеки Брюса Шнейєра для поглибленого обговорення надійності пароля.

Прочитайте цей PDF дослідників безпеки Філіп Інглесант та М. Анжела Сассе для поглибленого обговорення "Справжньої вартості непридатних політик пароля". Цитувати висновок:

Проти світогляду, що "якби тільки [користувачі] розуміли небезпеку, вони поводилися б інакше" [12], ми стверджуємо, що "якби тільки менеджери безпеки розуміли справжні витрати для користувачів та організації, вони встановлювали б політику по-різному".

Помилкове почуття безпеки

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

Для он-лайн доступу достатньо 6 символів

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

Якщо у вас є система паролів, яка знаходиться в режимі он-лайн, вам не потрібні паролі високої безпеки. Паролі мають бути достатньо складними, щоб не допустити здогадів протягом 20 спроб (тому проста атака "ім'я подружжя / дитини / домашньої тварини" не вдасться). Розглянемо наступний алгоритм:

1. Cracker вгадує пароль, використовуючи підхід «root плюс суфікс», щоб мінімізувати здогадки
2. Повноважні дані відхилені, а подальші спроби входу запобігли протягом N * 10 секунд
3. Якщо N> 20 заблокуйте рахунок і повідомте адміністратора
4. N = N +1
5. Повідомте користувача, що наступне вхід може відбутися в момент T (обчислено вище)
6. Перехід до кроку 1

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

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

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

Є один виняток. Якщо негативні наслідки порушення системи виявляться серйозними (наприклад, якщо дуже приватна інформація може бути порушена порушенням безпеки), ви насправді можете покладати професійний обов'язок не застосовувати потрібну систему. Не сподівайтеся, що він зробить вас популярними, якщо ви відмовитесь, але не дозволяйте це бути вашим посібником.

Я просто хочу підкріпити відповідь Мерфа. Так, це проблема безпеки, і в її реалізації є вразливості щодо розкриття інформації. Але, з точки зору клієнта, він, здається, не надто переживає з цього приводу.

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

Ви можете собі уявити, якщо у вас є 10 000 користувачів, і потрібно 30 секунд, щоб пройти пароль кожного користувача, щоб перевірити унікальність кожного разу, коли хтось новий підписується або змінює свій пароль?

Я думаю, що це відповідь, яку ви повинні прийняти до свого клієнта.

Поміркувавши з точки зору відповідного місця для запитання, розділ ІТ-безпеки Stack Exchange повинен стати для вас корисним пунктом. Спробуйте /security/tagged/passwords - коло людей, орієнтованих на ІТ-безпеку, має бути в змозі надати конкретні відповіді.

Ймовірно, він би хотів шифрування RSA двофакторним. Якщо ви використовуєте Active Directory або членство в ASP.NET, це не потрібно.

Апаратний або програмний маркер генерує унікальний час, який залежить від часу, а за ним - PIN-код. Це разом забезпечує унікальний пароль для кожного користувача.