Количество попыток взломать средний пароль / не навязчивые, но значимые ограничения?

Question

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

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

Это моя нынешняя схема:

• В форме входа используется одноразовый номер, поэтому злоумышленник должен дождаться завершения полного цикла запроса, чтобы получить как результат попытки входа в систему, так и получить новый токен.
• Я разрешаю 50 раз вводить форму входа для каждого IP-адреса с интервалом между запросами менее минуты, после чего IP-адрес будет заблокирован на 1 минуту. Любые новые попытки в течение этой одной минуты перезапустят тайм-аут.
• Для каждой выборки страницы входа в систему # of attempts / 5 применяется sleep, поэтому после 5 запросов с менее чем минутой между запросами для извлечения формы потребуется> 1 секунда, после 10 запросов > 2 секунды и т. Д.
• Кроме того, я разрешаю только 100 неудачных попыток входа в систему для каждой учетной записи пользователя с 2 часами между попытками, после чего учетная запись блокируется на 2 часа.
• Чтобы избежать частых DoS'ов для учетных записей, IP-адреса могут быть внесены в белый список (без ограничений) или в черный список (любая попытка входа в систему полностью игнорируется).

Основываясь на ответах, я настроил его так:

• Получение формы входа в систему постепенно замедляется для каждого IP-адреса. Каждый новый запрос спит в течение # of requests / 2 секунд. Счетчик сбрасывается через 10 минут без активности входа в систему.
• Я сохраняю стек попыток входа в FIFO для каждого IP. Если IP-адрес не может войти в систему 30 раз в течение 2 часов, он приостанавливается. Я также веду список количества приостановок на IP, и время приостановки рассчитывается как 2 ^ (# of suspensions + 1) hours. Это должно привести к быстрому фактическому внесению в черный список постоянно нарушающих IP-адресов.
• Кроме того, если учетная запись не смогла войти в систему 20 раз в течение одного дня, она будет приостановлена ​​на 2 часа. Я пока не слишком уверен в этом показателе, так как это означает, что учетные записи могут быть легко обработаны DoS. Если не считать массивного распределенного ботнета, то нарушающие IP-адреса должны быть де-факто помещены в черный список быстрее, чем учетная запись может быть постоянно DoS'd. Это также довольно эффективная мера для защиты учетной записи.

Я думаю, что эти ограничения не должны вредить обычным пользователям, даже тем, которые регулярно забывают свой пароль и пытаются войти в систему несколько раз. Ограничения IP-адреса также должны нормально работать с пользователями с большим количеством NAT, учитывая средний размер службы. Может ли кто-нибудь доказать, что это эффективно или неэффективно с какой-то твердой математикой? :)

Answer 1

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

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

Я много раз сталкивался с этой проблемой регулирования входа в систему, и мне нравится то, что вы создаете поле неудачных попыток и дату последней неудачной попытки в вашей базе данных. Всякий раз, когда кому-либо (кому-либо) не удается войти в учетную запись X, вы увеличиваете значение неудачных попыток X и обновляете дату последней неудачной попытки. Если число неудачных попыток превышает Y (например, пять), то покажите CAPTCHA для конкретного пользователя. Таким образом, у вас не будет огромной базы данных запрещенных IP-адресов для регулирования формы входа, вместо этого у вас будет всего два поля на пользователя. Также не имеет смысла запрещать / регулировать на основе IP-адресов из-за ботнетов и прокси (как легальных, так и нелегальных). Когда выйдет в моду IPv6, я полагаю, вы будете более обречены. Гораздо больше смысла регулировать на основе целевых учетных записей. Таким образом, когда ваша учетная запись X направляется ботнетом, форма входа будет ограничена CAPTCHA. Очевидным недостатком здесь является то, что если ваша CAPTCHA дает сбой ... то же самое происходит и при входе в систему.

Итак, по сути это выглядит так:

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

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

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

Надеюсь, это заставило вас задуматься.

Answer 2

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

• все строчные буквы: 26 ^ 6 = 308 915 776 возможных паролей = наихудший случай 12 лет , в среднем 6 лет
• строчные буквы и цифры: 36 ^ 6 = 82 года макс. , в среднем 41 год

Конечно, атаки по словарю будут намного быстрее, но у меня нет цифр для этого.

РЕДАКТИРОВАТЬ: я пытался связать результаты калькулятора Google, подкрепляя это, но ^, кажется, путает ссылки здесь.

EDIT2:

словарные атаки (от http://www.outpost9.com/files/WordLists.html):

• все перечисленные слова (75 000): ~ 1 день
• список из 816 общих паролей: ~ 16 минут
• действительно длинный список слов: ~ 12 дней (я посмотрел на это, и я предполагаю, что он содержит пароли большинства нетехнических людей)

Последний страшный, но 12 дней - это еще долго. Если вы действительно волнуетесь, вы можете отслеживать каждый неправильный пароль, пока пользователь не получит правильный пароль, а затем, если в списке будет более 100 попыток, просто заблокируйте IP-адрес и отправьте электронное письмо пользователю.

Answer 3

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

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

В таком случае изменение будет состоять в том, что при увеличении счетчика отказов до порогового значения поле блокировки устанавливается на now + 1 hour. Всякий раз, когда выполняется проверка подлинности, он просматривает это поле, и если lockout > now, то происходит сбой.

Ручная блокировка учетных записей с административной точки зрения становится просто вопросом установки поля блокировки на какое-то отдаленное будущее значение, например 9223372036854775807l (макс. Длина 64-битной подписи).