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

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

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

убедитесь, что тот, кто имеет реальную власть на сайте, имеет безопасный пароль. Требуются администраторы/ модераторы имеют более длинные пароли с сочетанием букв, цифр и символов. Отклонить тривиально простые пароли от обычные пользователи с объяснением.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

еще одна идея (без котят, хотя), чтобы отслеживать IP-адреса, которые пользователи получают доступ к системе С, и требовать от них выполнения дополнительных аутентификация (captcha, pick a kitty, pick a key from this table), когда они входят в систему с адреса, которого у них раньше не было. Кроме того, подобно GMail, позволяют пользователю просматривать, где они вошли в систему с недавнего времени.

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

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

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

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

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

Я уже отвечал на очень похожий вопрос на как я могу дросселировать попытки входа пользователя в PHP. Я повторю предлагаемое решение здесь, поскольку я считаю, что многие из вас найдут его информативным и полезным, чтобы увидеть некоторый фактический код. Пожалуйста, имейте в виду, что использование капчи может быть не лучшим решением из-за все более точных алгоритмов, используемых в 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;

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

---

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

---

запрашивать таблицу при каждой неудачной попытке входа, чтобы найти количество неудачных входов для a определенного периода времени, скажем 15 минут:

---

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

---

если количество попыток за данный период времени превышает ваш лимит, либо принудительно регулируйте, либо заставляйте всех пользователей использовать captcha (т. е. 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'S может быть разорен. Есть альтернативные решения, возможно вариант "назовите это животное", который вполне мог бы работать в качестве замены.

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

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

замечания:

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

эти наблюдения охватывают другой тип атаки на кого вы пытаетесь противостоять.

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

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

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

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

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

множественные методы можно совместить успешно, но хороший вкус определенно внутри порядок.

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

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

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

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

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

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

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

Edit: если вы ожидаете много ленивых атакующих, требующих некоторых капчи после нескольких неудачных попыток хорошо: это немного поднимает планку. Если вы беспокоитесь о большом количестве умных злоумышленников, нанять консультанта по безопасности. ;)

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

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

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

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

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

с вершины моего разума:

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

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

далее, как насчет другого вида капчи: вы есть ряд вопросов, которые не вызовут проблем для человека. Тем не менее, они не случайные. Когда начинается атака, всем задается вопрос №1. Через час Вопрос №1 отбрасывается, никогда не будет использоваться снова, и каждый получает Вопрос № 2 и так далее.

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

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

и рекапчи был взломан / взломан / ОРС / разбили / сломали?

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

вы также можете дросселировать на основе силы пароля пользователя.

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

Что-то вроде "пароль" забивает 1, тогда как "c6eqapRepe7et*Awr@ch" может забить 9 или 10, и чем выше оценка, тем больше времени требуется для дросселирования.

первый ответ, который я обычно слышал, задавая этот вопрос, - это изменение портов, но забудьте об этом и просто отключите IPv4. Если вы разрешаете только клиентам из сетей IPv6, вы больше не молитесь о простом сканировании сети, и злоумышленники будут прибегать к поиску DNS. Не запускайте по тому же адресу, что и ваш Apache(AAAA)/Sendmail(MX->AAAA)/что вы выдали всем (AAAA). Убедитесь, что ваша зона не может быть xferd, подождите, пока вы разрешите загрузить свою зону кто-нибудь?

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

** Проверьте ваши обратные (PTR) записи (под ip6.arpa.) чтобы увидеть, можно ли их использовать для обнуления в /4, у которых есть записи VS /4s, которые этого не делают. т. е. обычно ip6.arpa было бы ~32 "."s в адресе, но попытка с последними пропавшими без вести может ускользнуть сетевые блоки, которые имеют записи против других, которые не. Если взять, что в дальнейшем становится возможным пропускать большие участки адресного пространства.

в худшем случае пользователям придется настроить туннель IPv6, это не похоже на то, что им придется идти до VPNing в DMZ... Хотя интересно, почему это не первый вариант.

также Kerberos круто, но IMHO LDAP дует(что технически не так с NISPlus? Я читал, что Sun решила, что пользователи хотят LDAP и из-за этого они сбросили NIS+). Kerberos отлично работает без LDAP или NIS, просто нужно управлять пользователями на хосте по хосту. Использование Kerberos дает вам простой в использовании, если не автоматизированный, PKI.

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

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