Який найкращий контрзахід з розподіленою грубою силою?

По-перше, трохи досвіду: не секрет, що я впроваджую систему auth + auth для CodeIgniter, і поки що я виграю (так би мовити). Але я зіткнувся з досить нетривіальним викликом (той, який більшість авторських бібліотек повністю пропускає, але я наполягаю на правильному поводженні з ним): як розумно поводитися з широкомасштабними, розповсюдженими нападами грубої сили із змінними іменами .

Я знаю всі звичні хитрощі:

1. Обмеження кількості невдалих спроб на IP / хост і заборона доступу правопорушників (наприклад, Fail2Ban) - що більше не працює, оскільки ботнети стали розумнішими
2. Поєднуючи вищезазначене з чорним списком відомих «поганих» IP-адрес / хостів (наприклад, DenyHosts) - який покладається на ботнети, що потрапляють під №1, чого вони все частіше не роблять
3. Білі списки IP / хостів у поєднанні з традиційними аутентифікаціями (на жаль, марними для динамічних користувачів IP та високою чіткістю на більшості веб-сайтів)
4. Встановлення загальноміського обмеження на кількість невдалих спроб протягом N хвилини / години та придушення (призупинення) всіх спроб входу після цього протягом декількох хвилин / годин (з проблемою того, що DoS нападає на вас, стає грою дитини)
5. Обов’язкові цифрові підписи (сертифікати відкритого ключа) або апаратні жетони RSA для всіх користувачів, що не мають можливості входу / пароля (без сумніву, надійне рішення, але практичне лише для закритих спеціалізованих служб)
6. Розроблені надзвичайно сильні схеми паролів (наприклад,> 25 дурницьких символів із символами - знову ж таки непрактично для випадкових користувачів)
7. І нарешті, CAPTCHA (які можуть працювати в більшості випадків, але дратують користувачів і практично марні проти рішучого, винахідливого зловмисника )

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

• Він повинен бути захищеним (+) від DoS та жорстоких атак, а не вводити будь-які нові вразливості, які можуть дати змогу злегка прихованому боту продовжувати працювати під радаром

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

• Це повинно бути прийнятним для використання в мережі Інтернет (тобто, високий розмір, велика гучність та відкрита реєстрація, які можуть виконувати непрограмісти)

• Це не може перешкоджати користувальницькій роботі до того моменту, коли випадкові користувачі будуть роздратовані або розчаровані (і потенційно відмовляться від сайту)

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

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

Отже - давайте почуємо! Як би ти це зробив ? Чи знаєте ви про найкращу практику, яку я не згадував (о, будь ласка, скажіть, що ви робите)? Зізнаюся, у мене є своя ідея (поєднуючи ідеї 3 і 4), але я дозволю справжнім експертам говорити, перш ніж бентежити себе ;-)

Гаразд, достатньо затримки; ось що я придумав поки що

(Вибачте, довгий пост попереду. Будьте сміливі, друже, подорож того вартує)

Поєднуючи методи 3 та 4 з початкового допису у своєрідний «нечіткий» чи динамічний білий список, а потім - і ось ось хитрість - не блокувати IP-адреси, які не перебувають у списку, просто перекидаючи їх у пекло та назад .

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

Припущення щодо сценарію нападу

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

Тому нам потрібно зробити щось інше.

Перша частина контрзаходу: Білий список

У чому ми можемо бути впевнені, це те, що зловмисник не в змозі виявляти та динамічно підробляти IP-адреси декількох тисяч наших користувачів (+). Що робить білі списки здійсненними. Іншими словами: для кожного користувача ми зберігаємо список (хешованих) IP-адрес, з яких користувач раніше (недавно) увійшов.

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

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

Друга частина контрзаходу: загальносистемне придушення невпізнаних ІС

Для того, щоб зробити список білих списків для веб-сервісу відкритої реєстрації, де користувачі часто перемикають комп’ютери та / або підключаються з динамічних IP-адрес, нам потрібно тримати «котячу двері» відкритою для користувачів, що підключаються до нерозпізнаних IP-адрес. Хитрість полягає в тому, щоб створити двері таким чином, щоб ботнети застрягли, і так законних користувачів турбує якнайменше .

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

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

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

• Або підключившись до одного зі своїх визнаних IP-адрес
• Або за допомогою постійного файлу cookie для входу (з будь-якого місця)

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

Щоб дозволити цій невеликій підмножині користувачів просуватися через інакше запечатану котячу двері, навіть коли боти все ще забивали її, я б застосував форму для входу з резервною копією CAPTCHA. Отже, коли ви відображаєте повідомлення "Вибачте, але ви не можете увійти з цієї IP-адреси на даний момент", включіть посилання, яке говорить " безпечний вхід резервного копіювання - ЛЮДИНИ ТОЛЬКО ( боти: не брешуть ) ". Жартуйте вбік, коли натискають на це посилання, надайте їм реєстраційну форму для реєстрації, підтверджену reCAPTCHA, що обходить сторону загального веб-сайту. Таким чином, якщо вони люди І знають правильний логін + пароль (і вміють читати CAPTCHA), їм ніколи не буде відмовлено в обслуговуванні, навіть якщо вони підключаються від невідомого хоста і не використовують cookie autologin.

О, і просто для уточнення: Оскільки я вважаю CAPTCHA загалом злим, параметр входу в систему "резервного копіювання" з'явиться лише тоді, коли активування дроселя .

Не можна заперечувати, що така тривала атака, як і раніше, буде формою DoS-атаки, але при наявності описаної системи вона вплине лише на те, що я підозрюю, що є крихітним набором користувачів, а саме людьми, які не використовують Файли cookie "запам'ятайте мене" І входять під час вступу в атаку. І не входять в систему з будь-яких звичних IP-адрес І не вміють читати CAPTCHA. Під час бот-атаки будуть відвернені лише ті, хто може сказати "ВСІМ" цим критеріям - зокрема ботам та справді нещасним інвалідам.

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

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

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

Кілька простих кроків:

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

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

Одне з найпростіших речей, яке ви можете зробити, - це повідомити людям, коли хтось намагався увійти у свій обліковий запис, і надати їм посилання, щоб повідомити про інцидент, якщо це не вони. Просте повідомлення, коли вони входять у систему, як-от "Хтось спробував увійти до вашого акаунта о 4:20 ранку, се-бла. Клацніть тут, якщо це не ви". Це дозволяє вести деяку статистику щодо атак. Ви можете посилити моніторинг та заходи безпеки, якщо побачите, що раптово зростає шахрайський доступ.

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

Є дві пропозиції, які, я думаю, ще не бачив тут:

• Я завжди вважав, що стандартною практикою є коротка затримка (секунда або близько того) після неправильного входу для кожного користувача. Це стримує грубу силу, але я не знаю, як довго затримка на одну секунду триматиме атаку словника. (словник з 10 000 слів == 10000 секунд == близько 3 годин. Хм. Недостатньо.)
• замість того, щоб загальмувати загальний веб-сайт, чому б не увімкнути ім'я користувача. Дросель стає все більш різким із кожною помилковою спробою (до певної межі, я думаю, щоб справжній користувач все одно міг увійти)

Редагувати : У відповідь на коментарі до дроселя імені користувача: це дросель, визначений для імені користувача, без огляду на джерело атаки.

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

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

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

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

Додаткові вдосконалення:

• виявити IP-адреси, які вгадують декілька облікових записів - 408 Запит на очікування
• виявити IP-адреси, які вгадують той самий рахунок - 408 Запит часу на очікування після великої (скажімо, 100) кількості здогадок.

Ідеї ​​користувальницького інтерфейсу (можливо, не підходять у цьому контексті), які також можуть уточнити вищезазначене:

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

Існує три фактори аутентифікації:

1. Користувач щось знає (тобто пароль)
2. У користувача є щось (наприклад, брелок для ключів)
3. Користувач - це щось (тобто сканування сітківки)

Зазвичай веб-сайти застосовують лише політику №1. Навіть більшість банків застосовують лише політику 1. Натомість вони покладаються на "знає щось інше" підхід до двофакторної аутентифікації. (IE: Користувач знає свій пароль та дівоче прізвище матері.) Якщо ви в змозі, спосіб додати другий фактор аутентифікації не надто складний.

Якщо ви можете генерувати близько 256 символів випадковості, ви можете структурувати це в таблиці 16 × 16, а потім попросити користувача вказати вам значення, наприклад, у таблиці клітинки A-14. Коли користувач підписує або змінює свій пароль, дайте їм таблицю і скажіть, щоб вони роздрукували її і зберегли.

Складність такого підходу полягає в тому, що коли користувач забуде свій пароль, як і буде, ти не можеш просто запропонувати стандартний "відповісти на це запитання та ввести новий пароль", оскільки це вразливе і для грубої сили. Крім того, ви не можете скинути його та надіслати їм новий електронний лист, оскільки їх електронний лист також може бути порушений. (Див. Makeuseof.com та їх викрадений домен.)

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

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

Редагувати, нова ідея:

Інший спосіб перевірки спроб входу - це перевірити, чи прийшов користувач зі своєї сторінки входу. Ви не можете перевірити рефератів, оскільки їх можна легко підробити. Що вам потрібно - це встановити ключ у варі _SESSION, коли користувач переглядає сторінку входу, а потім перевірте, чи є ключ, коли він подає інформацію про вхід. Якщо бот не подає з сторінки входу, він не зможе увійти. Ви також можете полегшити це, включивши JavaScript у процес, або використовуючи його для встановлення файлу cookie, або додавши інформацію до форми після завантаження. Або ви можете розділити форму на два різних подання (тобто користувач вводить своє ім'я користувача, подає, потім на новій сторінці вводить свій пароль і знову надсилає.)

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

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

Ви не можете просто запобігти DoS-атакам, прив'язуючи призупинення до одного IP-адреса або імені користувача. Чорт, ти навіть не можеш реально попередити спроби входу з швидким вогнем за допомогою цього методу.

Чому? Оскільки атака може охопити кілька IP-адрес та облікових записів користувачів заради обходу ваших спроб дроселювання.

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

CREATE TABLE failed_logins(
    id INT(11) UNSIGNED NOT NULL AUTO_INCREMENT PRIMARY KEY,
    username VARCHAR(16) NOT NULL,
    ip_address INT(11) UNSIGNED NOT NULL,
    attempted DATETIME NOT NULL
) engine=InnoDB charset=UTF8;

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

10 failed attempts = 1 second
20 failed attempts = 2 seconds
30 failed attempts = reCaptcha

Запросіть таблицю щодо кожної невдалої спроби входу, щоб знайти кількість невдалих реєстрацій за певний проміжок часу, скажімо, 15 хвилин:

SELECT COUNT(1) AS failed FROM failed_logins WHERE attempted > DATE_SUB(NOW(), INTERVAL 15 minute);

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

// array of throttling
$throttle = array(10 => 1, 20 => 2, 30 => 'recaptcha');

// assume query result of $sql is stored in $row
$sql = 'SELECT MAX(attempted) AS attempted FROM failed_logins';
$latest_attempt = (int) date('U', strtotime($row['attempted']));
// get the number of failed attempts
$sql = 'SELECT COUNT(1) AS failed FROM failed_logins WHERE attempted > DATE_SUB(NOW(), INTERVAL 15 minute)';
// assume the number of failed attempts was stored in $failed_attempts
krsort($throttle);
foreach ($throttle as $attempts => $delay) {
    if ($failed_attempts > $attempts) {
        // we need to throttle based on delay
        if (is_numeric($delay)) {
            $remaining_delay = time() - $latest_attempt - $delay;
            // output remaining delay
            echo 'You must wait ' . $remaining_delay . ' seconds before your next login attempt';
        } else {
            // code to display recaptcha on login form goes here
        }
        break;
    }
}

Використання reCaptcha під певним порогом гарантувало б, що атака з декількох фронтів буде мінімізована, а звичайні користувачі сайту не зазнають значної затримки при законних спробах входу. Я не можу запобігти гарантіям, оскільки це вже було розширено, коли CAPTCHA може бути розбитий. Є альтернативні рішення, можливо, варіант "Назвіть цю тварину", який міг би справитись як заміна.

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

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

Для узагальнення схеми Йенса в діаграму / базу правил переходу до псевдо стану:

1. користувач + пароль -> запис
2. user +! пароль -> відхилено
3. user + known_IP (user) -> вхідні двері, // never throttle
4. user + unknown_IP (user) -> catflap
5. (#denied> n) через catflaps (сайт) -> дросельні заслонки (сайт) // slow the bots
6. catflap + дросель + пароль + captcha -> запис // humans still welcome
7. catflap + дросель + пароль +! captcha -> відхилено // a correct guess from a bot

Спостереження:

• Ніколи не заглушуйте вхідні двері. Державна поліція Елбона має ваш комп'ютер у вашому домі, але не може вас допитати. Груба сила - це життєздатний підхід з вашого комп’ютера.
• Якщо ви вкажете "Забули пароль?" посилання, то ваш обліковий запис електронної пошти стане частиною поверхні атаки.

Ці спостереження охоплюють різний тип атаки до тих, з якими ви намагаєтесь протидіяти.

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

Відмова: Я працюю в двофакторній компанії, але не тут, щоб підключити її. Ось кілька спостережень.

Файли cookie можуть бути викрадені за допомогою XSS та веб-переглядачів браузера. Користувачі зазвичай змінюють веб-переглядачі або очищають файли cookie.

Джерела IP-адреси одночасно динамічно змінні та підлягають підключенню.

Captcha корисна, але не підтверджує автентичності конкретної людини.

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

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

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

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

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

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

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

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

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

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

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

З самого початку:

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

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

Далі, як щодо різного роду капчу: у вас є ряд питань, які не спричинять проблем для людини. Однак вони НЕ є випадковими. Коли напад починається, всім надається питання №1. Через годину питання №1 відміняється, його більше не використовувати, і кожен отримує питання №2 тощо.

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

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

Чи було зламано / зламано reCaptcha / OCR'd / переможений / зламаний?

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

Ви також можете вимкнути ґрунт залежно від міцності пароля користувачів.

Коли користувач реєструє або змінює свій пароль, ви обчислюєте ступінь міцності для свого пароля, скажімо, від 1 до 10.

Щось на кшталт "пароль" набирає бал 1, тоді як "c6eqapRepe7et * Awr @ ch" може набрати 9 або 10 і чим більший бал, тим більше часу потрібно для дроселювання.

Перша відповідь, яку я зазвичай чув, задаючи це питання, - це змінити порти, але забути про це і просто відключити IPv4. Якщо ви дозволите клієнтам з мереж IPv6, ви більше не будете молитися за просте сканування мережі, і зловмисники вдаватимуться до пошуку DNS. Не бігайте за тією ж адресою, що і Apache (AAAA) / Sendmail (MX-> AAAA) / що ви видали всім (AAAA). Переконайтеся, що вашу зону не може бути xferd, зачекайте, коли ви дозволите, щоб вашу зону хтось завантажував?

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

** Перевірте свої зворотні (PTR) записи (під ip6.arpa.), Щоб побачити, чи можна їх використовувати до нуля в / 4, які мають записи VS / 4, які не мають. IE Зазвичай ip6.arpa має адресу 32 ".", Але спроба з останніми кількома відсутніми може уникнути мережевих блоків, у яких є записи VS, які не мають. Якщо взяти це далі, то можна пропустити великі частини адресного простору.

У гіршому випадку користувачам доведеться встановити тунель IPv6, це не так, як їм доведеться зайти до VPNing в DMZ ... Хоча хтось цікавиться, чому це не перший варіант.

Також Kerberos крутий, але IMHO LDAP дує (Що технічно не в порядку з NISPlus? Я читав, що Sun вирішив, що користувачі хочуть LDAP, і через це вони скинули NIS +). Kerberos добре працює без LDAP або NIS, просто потрібно керувати користувачами на хості за допомогою хоста. Використання Kerberos дає простий у використанні, якщо не автоматизований, PKI.

Трохи пізно тут, але я думав, припускаючи важкий випадок - зловмисник використовує безліч випадкових IP-адрес, випадкових імен користувачів та випадкового пароля, вибраного із списку 10 000 найпопулярніших.

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