Покарання користувачів за незахищені паролі [закрито]

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

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

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

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

ЯГНІ , KISS , DRY , правило 10 секунд і той факт, що "[у] серці не піклуються про ВАС", мабуть, повинні звузити це до одного рішення: Не.

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

Будьте змушені захистити пароль при зміні реєстрації або скористайтеся OpenId (Jeff Atwood's 2c: http://www.codinghorror.com/blog/2010/11/your-internet-drivers-license.html ). Тоді зосередьтеся на більш цікавій функціональності.

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

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

Моя відповідь справді зводиться до KISS .

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

Не зрозумійте мене неправильно, безпека важлива. Але якщо ви не повинні дратувати користувачів, якщо у вас немає поважних причин вірити, що хтось спробує зламати свої паролі, щоб отримати доступ до вашого сайту. Якщо ваш сайт надає доступ VPN до мережі ФБР, продовжуйте дратувати. Але якщо це форум користувача, де кожен, хто має адресу електронної пошти, може зареєструватися, який сенс насправді?

Краще рішення: усміхнені обличчя.

Я серйозно! Читання книг з питань поведінкової економіки на кшталт "Поштовх: вдосконалення рішень про здоров'я, добробут та щастя" переконало мене в кількох речах:

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

Я бачу, що такі принципи стосуються вашої ситуації так:

1. Обмеження користувачів на основі небезпечних паролів, швидше за все, зірве і заплутає їх ... особливо для більшості людей, які не читають ретельно написаних пояснень у діалогових вікнах, а просто дзвонять у службу підтримки, щоб сказати: "Це не так робота ».
2. Створюючи паролі, користувачам не потрібно бачити список усіх можливостей спеціальних символів і таких, якими вони можуть користуватися. Краще покажіть їм невеликі спливаючі вікна, що дозволяють додати певну складність, лише якщо їх запис не відповідає вимогам.
3. На людей сильно впливають соціальні підказки - навіть маленькі, як щасливі обличчя, показують, що ми схвалюємо їх поведінку, або хмурі обличчя, якщо ми цього не робимо. На деяких краще розроблених веб-сайтах відображатиметься кольорова смужка прогресу, яка змінюється на червону на Недостатньо хороша :( на зелену для Хорошої роботи! :), як користувач вводить свій (запропонований) пароль та підтвердження. Цей інтерфейс надає їм певний соціальний тиск для дотримання стандартів - змусити планку стати зеленою або змінити нахмурене посмішку - коли вони відкриють для себе, як створити більш безпечні паролі за допомогою негайного зворотного зв’язку зміни кольору.

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

Якщо це продукт, який матиме представників служби підтримки клієнтів за ним, їм це не сподобається дуже. Одне з основних припущень підтримки полягає в тому, що вони розуміють і можуть передбачити користувацький досвід - якщо вони допомагають звичайному користувачеві, тоді Сторінка 1 повинна мати посилання на Сторінки 2, 3 і 4, де вони можуть робити X, Y, Z тощо.

Тепер ви даєте їм ще одну змінну, яку вони повинні відстежувати. Якщо користувач не бачить посилання на сторінку 4, це тому, що вони зробили щось дурне? Або це тому, що їхній пароль відсмоктується, і ваша система карає їх, забороняючи їм доступ до сторінки 4? Зачекайте ... лайно, забороняєте доступ до одного з покарань за неправильний пароль, чи я думаю про сторінку 5? Дозвольте роздивитись, лише одну мить ... гаразд, це говорить, що для пароля, який не змішує великі і малі літери, доступ до сторінок з парними нумерами дозволений, але обмежений лише для читання ... добре, сер, ваш пароль, чи складається він з усіх великих літер або з малих літер? Справа. Коли ви просто набираєте букву, це нижчі регістри; коли ви використовуєте shift, тоді це верхній регістр. Ви змішали випадки у своєму паролі? Пароль, який ви використовували для входу в систему. Той, який ти щойно використав. Гаразд, перейдіть до "Правка", потім виберіть "Налаштування", а потім "Безпека". Виберіть "Збережені паролі" ... ні, сер, я не бачу ваших паролів звідси ....

Так. Не робіть цього.

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

і чи може він розташовуватися у веселковому столі

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

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

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

На час хешування: Подумайте про час очікування 500мм для механізму входу. Я думаю, що це прийнятно ... (нагадування: майже одну секунду тремтять руку для SSL)