Слабкі сторони 3-страйкової безпеки

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

Так, це зробить неможливими атаки на словник через механізм входу . (Це все ще не означає, що якщо вони отримують доступ до бази даних. Для безпеки там вам потрібно буде правильно розмістити паролі та солити паролі.)

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

Я також погоджуюся, що це робить атаки на словники менш ефективними, як способи отримати доступ до облікового запису без відповідних повноважень. Однак:

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

• Як було сказано в іншій відповіді, це також може перетворити атаку словника в грубу DOS проти легітимного власника облікового запису, який атакується. Способи пом'якшення впливу на законного власника включають:

  • Уповільнення запуску імен користувачів, не даючи жодних підказок щодо того, неправильно це ім’я користувача або пароль. Це робить атаки, коли винуватець відгадує імена користувачів, більш помітні для адміністраторів і менш ефективні.
  • Замість того, щоб заблокувати обліковий запис після фіксованої кількості невдалих спроб, просто заблокуйте цей режим аутентифікації. Іншими словами, вимагайте, щоб користувач, на якого підпадають атаки, підтверджував автентифікацію, використовуючи інший (можливо більш задіяний, але менш атакований) метод Хороший приклад - те, як Android-телефон вимагатиме від користувача своєї інформації для входу в Google після автентифікації, використовуючи шаблон розблокування екрана або PIN-код. Теоретично це схоже на те, щоб вимагати, щоб атакований користувач попросив розблокувати свій обліковий запис, однак, це не вимагає негайного втручання системного адміністратора.
  • Замість блокування облікового запису (або на додаток до блокування облікового запису, для цього конкретного режиму аутентифікації - див. Вище) блокуйте спроби аутентифікації з місця, де відбувається атака. Наприклад, якщо автентифікація проводиться через ім'я користувача та пароль через мережу, після трьох невдалих спроб аутентифікації ви можете запобігти подальшим спробам користувачів з того ж IP-адреси або підмережі входити в систему за допомогою імені користувача або пароля. Якщо є хороший шанс, що кілька користувачів (включаючи зловмисника) могли використовувати один і той же IP або підмережу, ви можете просто відключити автентифікацію імені користувача / пароля для IP або підмережі протягом певного часу, залишаючи відкриті більш задіяні методи аутентифікації для невинних користувачів, що знаходяться в безпосередній близькості від зловмисника.

• Якщо ваш страх ненавмисно карає забудькуватого користувача, як ніби він є зловмисником, замість того, щоб контролювати потік невдалих спроб входу після фіксованої кількості невдалих спроб, ви можете використовувати частоту спроб входу як доказ атаки облікового запису. Наприклад, якщо ви бачите 10 спроб аутентифікації протягом проміжку секунди, ви можете скористатися одним із наведених вище способів, щоб запобігти подальшим подібним спробам аутентифікації. Крім того, ви можете використовувати це швидке затоплення спроб входу як сигнал для початку управління потоком. Цей метод стає все більш популярним на форумах, тоді як після певної кількості невдалих спроб входу з певного ІС цей IP не може бути автентифікований на короткий проміжок часу.

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

У будь-якому випадку, я сподіваюся, що вам допоможе одна чи якась комбінація цих підходів.