Какая лучшая контрмера для распределенной грубой силы?

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

От вершины моего ума:

Переключатель на альтернативный экран входа в систему. Это имеет несколько имя пользователя и пробелы пароля, которые действительно появляются, но только один из них находится в правильном месте. Имена полей СЛУЧАЙНЫ - сеансовый ключ отправляется наряду с экраном входа в систему, сервер может затем узнать то, что поля что. Успешно выполнитесь или перестаньте работать, это затем отбрасывается так, Вы не можете попробовать атаку с повторением пакетов - при отклонении пароля, они получают новый идентификатор сессии.

Любая форма, которая отправлена с данными в неправильном поле, принята, чтобы быть от робота - сбои входа в систему, точка, и тот IP регулируют. Удостоверьтесь, что имена случайного поля никогда не соответствуют законным именам полей так кто-то использующий что-то, что помнит, что пароли не, вводят в заблуждение.

Затем, как насчет другого вида капчи: у Вас есть серия вопросов, которые не вызовут проблемы для человека. Однако они НЕ случайны. Когда нападение запускается, всем дают вопрос № 1. После того, как вопрос часа № 1 отбрасывается, чтобы никогда не использоваться снова, и все получают вопрос № 2 и так далее.

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

1. Что относительно того, чтобы требовать одноразового пароля прежде, чем ввести их нормальный пароль? Это сделало бы это очень очевидным, что кто-то нападал, прежде чем они получили много возможностей предположить основной пароль?

2. Проводят глобальный подсчет отказов входа в систему - это - индикатор для нападения - во время нападения быть более строгим об отказах входа в систему, например, запретить дюйм/с более быстро.

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

Несколько простых шагов:

Черный список определенные общие имена пользователей, и используют их в качестве ловушки. Администратор, гость, и т.д. не позволяет никому создать учетные записи с этими именами, поэтому если кто-то действительно пытается зарегистрировать их в Вас, знают, что это - кто-то делающий что-то, что они не были должны.

Удостоверяются любой, у кого есть действительная мощность на сайте, имеет безопасный пароль. Потребуйте, чтобы у администраторов / модераторы были более длительные пароли с соединением букв, чисел и символов. Отклоните тривиально простые пароли от обычных пользователей с объяснением.

Одна из самых простых вещей, которые можно сделать, говорят людям, когда кто-то пытался войти в их учетную запись и дать им ссылку для создания отчетов об инциденте, если это не были они. Простое сообщение, когда они входят в систему как "Кто-то, пыталось войти в Вашу учетную запись в 4:20 в среду и тому подобное. Щелкните здесь, если это не было Вами". Это позволяет Вам сохранить некоторую статистику по нападениям. Можно повысить мер контроля и мер безопасности, если Вы видите, что существует внезапное увеличение мошеннических доступов.

Если я понимаю MO атак перебором правильно, то одни или несколько имен пользователей пробуют непрерывно.

существует два предложения, которые я не думаю, что видел все же здесь:

• я всегда думал, что общепринятая практика состояла в том, чтобы иметь малую задержку (приблизительно секунда) после каждого неправильного входа в систему для каждого пользователя. Это удерживает "в лоб", но я не знаю, сколько времени одна вторая задержка держала бы атаку с подбором по словарю в страхе. (словарь 10 000 слов == 10 000 секунд == приблизительно 3 часа. Хм. Не достаточно хороший.)
• вместо по всему сайту замедляются, почему не дроссель имени пользователя. Дроссель становится все больше резким с каждой неправильной попыткой (до предела, наверное реальный пользователь может все еще войти в систему)

Редактирование : В ответ на комментарии к дросселю имени пользователя: это - имя пользователя определенный дроссель без учета к источнику нападения.

, Если имя пользователя регулируют, то даже скоординированное нападение имени пользователя (много IP, единственное предположение на IP, то же имя пользователя) было бы поймано. Отдельные имена пользователей защищены дросселем, даже если взломщики свободны судить другого пользователя/передачу во время тайм-аута.

С точки зрения взломщиков, во время тайм-аута Вы можете брать в первый раз, когда предполагают 100 паролей и быстро обнаруживают один неправильный пароль на учетную запись. Можно только смочь высказать 50-секундные предположения в течение того же периода времени.

С точки зрения учетной записи пользователя, это все еще берет то же среднее количество предположений для повреждения пароля, даже если предположения прибывают из многочисленных источников.

Для взломщиков, в лучшем случае это будет то же усилие повредить 100 учетных записей, как это было бы 1 учетная запись, но так как Вы не регулируете на сайте широкое основание, можно увеличить дроссель вполне быстро.

Дополнительные улучшения:

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

идеи UI (может не подойти в этом контексте), который может также совершенствовать вышеупомянутое:

• , если Вы управляете установкой пароля, затем показывая пользователю , насколько сильный их пароль , поощряет их выбирать лучший.
• , если Вы управляете входом в систему страница после маленького (говорят 10) количество предположений единственного имени пользователя, предложите КАПЧУ.

Существует три фактора аутентификации:

1. пользователь А знает что-то (т.е., пароль)
2. , пользователь А имеет что-то (т.е., брелок)
3. , пользователь А что-то (т.е., сканирование сетчатки)

Обычно, веб-сайты только осуществляют политику № 1. Даже большинство банков только осуществляет политику 1. Они вместо этого полагаются, "знает, что что-то еще" приближается к двухфакторной аутентификации. (IE: пользователь знает их пароль и девичью фамилию их родительского элемента.), Если Вы можете, способ добавить во втором факторе аутентификации не является слишком трудным.

, Если можно генерировать приблизительно 256 символов случайности, Вы могли бы структурировать это в 16× 16 таблиц, и затем просят, чтобы пользователь дал Вам значение в таблице ячейки A-14, например. Когда пользователь подпишется или изменит их пароль, дайте им таблицу и скажите им печатать ее прочь и сохранять ее.

трудность с тем подходом состоит в том, что, когда пользователь забывает их пароль, как они будут, Вы не можете только предложить стандарт, "отвечают на этот вопрос и вставляют новый пароль", так как это уязвимо для "в лоб" также. Кроме того, Вы не можете сбросить его и послать им по электронной почте нового, так как их электронная почта могла быть поставлена под угрозу также. (См.: Makeuseof.com и их украденный домен.)

Другая идея (который включает котят), то, что BOA называет SiteKey (я полагаю, что они регистрировали имя как торговую марку). Кратко, Вы сделали, чтобы пользователь загрузил изображение, когда они регистрируются, и когда они пытаются войти в систему, попросите, чтобы они выбрали свое изображение из 8 или 15 (или больше) случайные. Так, если пользователь загружает картинку их котенка, теоретически только они знают точно, какое изображение их из всех других котят (или цветы или безотносительно). Единственный реальный vunerability, который имеет этот подход, является атакой "человек посередине".

Еще одна идея (никакие котята, хотя), должен отследить дюйм/с, что пользователи получают доступ к системе с и требуют, чтобы они выполнили дополнительную аутентификацию (капча, выберите котенка, выберите ключ от этой таблицы), когда они входят в систему от адреса, они не имеют прежде. Кроме того, подобный Gmail, позвольте пользователю просматривать, где они вошли в систему от недавно.

Редактирование, Новая Идея:

Другой способ проверить попытки входа в систему состоит в том, чтобы проверить, произошел ли пользователь из Вашей страницы входа в систему. Вы не можете проверить ссылающиеся домены, так как они могут легко фальсифицироваться. То, в чем Вы нуждаетесь, должно установить ключ в _SESSION var, когда пользователь просматривает страницу входа в систему, и затем проверьте, чтобы удостовериться, что ключ существует, когда они отправляют свои данные для входа. Если бот не отправит от страницы входа в систему, то он не сможет войти в систему. Можно также упростить это путем вовлечения JavaScript в процессе, или при помощи его для установки cookie, или добавления некоторой информации к форме после того, как это загрузилось. Или, можно развестись, форма в два различных отправляет (т.е., пользователь вводит их имя пользователя, отправляет, затем на новой странице вводит их пароль, и отправьте снова.)

ключ, в этом случае, является самым важным аспектом. Общепринятая методика генерации их является некоторой комбинацией данных пользователя, их IP, и время, это было отправлено.

Я должен спросить, сделали ли Вы анализ рентабельности этой проблемы; это кажется, что Вы пытаетесь защитить себя от взломщика, у которого есть достаточно веб-присутствия для предположения многих паролей, отправляя, возможно, 3-5 запросов на IP (так как Вы отклонили регулировку IP). Какого количества (примерно) стоило бы такое нападение? Действительно ли это более дорого, чем значение учетных записей, которые Вы пытаетесь защитить? Сколько гигантских ботнетов хочет то, что Вы имеете?

ответ мог бы быть нет - но если это, я надеюсь, что Вы получаете справку от какого-то специалиста по безопасности; программирование навыка (и счет StackOverflow) не коррелирует сильно к ноу-хау безопасности.

Суммировать схему Jens в псевдо диаграмму изменения состояний / база правил:

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

Наблюдения:

• Никогда не регулируют парадную дверь. Государственная полиция Elbonian имеет Ваш компьютер, в Вашем доме, но не может опросить Вас. Грубая сила является жизнеспособным подходом от Вашего компьютера.
• , Если Вы предоставляете "Forgetten свой пароль?" ссылка, затем Ваш почтовый ящик становится частью поверхности атаки.

Эти наблюдения покрывают другой тип нападения тем, Вы пытаетесь противостоять.

Так как несколько человек включали КАПЧУ как механизм человека нейтрализации, я добавляю более ранний вопрос о StackOverflow и поток на эффективности КАПЧИ.

reCaptcha был взломан / взломанный / OCR’d / побежденный / поврежденный?

Используя КАПЧУ не ограничивает улучшения от Вашей регулировки и других предложений, но я думаю количество ответов, которые включают КАПЧУ, поскольку нейтрализация должна считать человечески-основанные методы доступными людям, обращающимся к безопасности повреждения.

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

Я действительно поймал кого-то, кто взломал учетную запись моего брата myspace, потому что они пытались проникнуть учетную запись Gmail, которую я установил для него, и использовал функцию «сбросить пароль по электронной почте» ... которая попала в мой почтовый ящик.

Заявление об ограничении ответственности: я работаю в двухфакторной компании, но я здесь не для того, чтобы подключать ее. Вот некоторые наблюдения.

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

Исходные IP-адреса одновременно динамически изменяются и поддаются подмене.

Captcha полезна, но не аутентифицирует конкретного человека.

Несколько методов можно успешно комбинировать, но это хорошо вкус, конечно, в порядке.

Сложность пароля хороша, все, что основано на паролях, критически зависит от паролей, имеющих достаточную энтропию. ИМХО, надежный пароль, записанный в надежном физическом месте, лучше, чем надежный пароль в памяти. Люди гораздо лучше знают, как оценивать безопасность бумажных документов, чем вычислять эффективную энтропию клички своей собаки, которая используется в качестве пароля для трех разных веб-сайтов. Подумайте о том, чтобы дать пользователям возможность распечатать большую или маленькую страницу, полную одноразовых кодов доступа.

Вопросы безопасности, такие как «каким был ваш школьный талисман», в большинстве своем являются еще одной мерзкой формой «чего-то, что вы знаете». из них легко угадать или прямо в открытом доступе.

Как вы отметили, ограничение неудачных попыток входа в систему - это компромисс между предотвращением атак методом грубой силы и простотой DoS-атаки для учетной записи. Политика агрессивной блокировки может отражать неуверенность в энтропии паролей.

Я лично не вижу пользы от принудительного истечения срока действия пароля на веб-сайте. Злоумышленник получает ваш пароль один раз, а затем может изменить его и соблюдать эту политику так же легко, как и вы. Возможно, одно из преимуществ заключается в том, что пользователь может раньше заметить, если злоумышленник изменит пароль учетной записи. Еще лучше было бы, если бы пользователь каким-то образом был уведомлен до того, как злоумышленник получил доступ. В этом отношении полезны сообщения типа «N неудачных попыток с момента последнего входа в систему».

Наилучшая безопасность обеспечивается вторым фактором аутентификации, который является внеполосным по сравнению с первым. Как вы сказали, аппаратные токены в «кое-что у вас есть» - это здорово, но многие (не все) имеют реальные административные издержки, связанные с их распределением. Я не знаю ни одного биометрического "то, что ты есть" решения, подходящие для веб-сайтов. Некоторые двухфакторные решения работают с поставщиками openid, некоторые имеют SDK для PHP / Perl / Python.

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

Вы не можете просто предотвратить 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;

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

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 могут быть взломаны. Существуют альтернативные решения, возможно, вариант "Назовите это животное", который вполне мог бы работать в качестве замены.