Это эффективный способ предотвратить атаки методом перебора?

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

  1. Если пользователь неправильно наберет пароль к аккаунту 5 раз, они будут заблокированы на 5 минут.
  2. После блокировки в мою базу данных добавляется запись, содержащая user_id и время, когда пользователь может попытаться снова войти в эту учетную запись.
  3. По истечении 5 минут, когда они в следующий раз попытаются войти в систему, он проверит базу данных, чтобы увидеть, не истекло ли время блокировки. Если это так, у них есть еще 5 попыток, если нет - выдает ошибку.

Это защита от взлома?

Спасибо.


security brute-force
person Community    schedule 16.10.2014    source источник
comment
Вам нужен механизм, позволяющий законному пользователю, который забыл свой пароль, «сбросить» период блокировки грубой силы.   -  person Shiva    schedule 16.10.2014
comment
Вы также можете использовать капчу.   -  person Ricardo Alvaro Lohmann    schedule 16.10.2014
comment
Длинные парольные фразы все еще кажутся мне лучшей идеей, потому что они могут заблокировать многих законных пользователей.   -  person Shomz    schedule 16.10.2014
comment
Может ли злоумышленник иметь бесконечное время? Если это так, то на самом деле ничто не является доказательством грубой силы.   -  person Elliott Frisch    schedule 16.10.2014
comment
Привет! Я вижу, что вы новичок в stackoverflow, но, пожалуйста, не добавляйте свои вопросы в избранное. Это не сделает его более популярным, и вы будете получать уведомления о нем, даже если он не добавлен в избранное.   -  person markasoftware    schedule 16.10.2014
comment
даже без этого, поскольку он находится в сети, время, необходимое для отправки одного запроса на вход в систему, быстрое, но все же достаточно долгое, чтобы обеспечить безопасность без периода блокировки   -  person markasoftware    schedule 16.10.2014
comment
@Shiva Какие бывают механизмы?   -  person    schedule 16.10.2014
comment
Вы можете просто построить свой собственный. Это довольно просто.   -  person Malcolm Kindermans    schedule 16.10.2014

Ответы (5)


arrow_upward
5
arrow_downward

Существует очень старый и пока что лучший метод предотвращения грубой силы. Он возник много лет назад в unix и до сих пор действует. Это также очень просто реализовать: добавляйте sleep (3) к каждой попытке входа в систему. У обычного пользователя не будет проблем с ожиданием дополнительных 3 секунд при входе в систему, и это в сочетании с надлежащим брандмауэром, ограничивающим количество подключений с одного хоста, является наиболее эффективным убийцей грубой силы.

person Tymoteusz Paul    schedule 16.10.2014
comment
+1 Я согласен, что время (пока) хороший способ предотвратить брутфорс. i.imgur.com/XuMUU0b.gif - person Shomz; 16.10.2014
comment
И такое замедление умножает любую попытку взлома в тысячи раз. Немного забавно, как изобретение из эпохи коммутируемого подключения все еще так эффективно, даже несмотря на то, что оно использовалось из-за того, что не было места для хранения всех сетевых журналов и выборочного запрета на основе количества попыток. Как это обычно бывает - простота продается. - person Tymoteusz Paul; 16.10.2014

arrow_upward
2
arrow_downward

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

  • 1-й сбой: задержка 1 сек.
  • 2-й сбой: задержка 2 секунды
  • 3-я ошибка: задержка 4 секунды
  • 4-я ошибка: задержка 8 секунд
  • и т.д...

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

length

person Shomz    schedule 16.10.2014
comment
Как это защищает от атак грубой силы? Как бы вы проверили, была ли это первая, вторая и т. Д. Попытка входа в систему? Очень легко начинать новый сеанс с каждой попытки или отправлять несколько запросов параллельно ... - person inf3rno; 04.11.2014
comment
@ inf3rno Подумайте о ресурсах, необходимых для инициирования каждого входа в систему с новым сеансом / IP для взлома длинного пароля ... это так же дорого, как масштабная DDOS-атака. Нет конечной защиты от атаки грубой силы, все, что вы можете сделать, это выиграть больше времени и заставить их сдаться. - person Shomz; 04.11.2014

arrow_upward
1
arrow_downward

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

Я использую аналогичную стратегию - после 5 неудачных попыток мы запрашиваем капчу. После 10 неудачных попыток мы блокируем аккаунт до сброса. У нас также есть стратегия сброса пароля и разблокировки.

Кто-то упомянул стратегию сна (3). Хотя не рекомендуется слишком быстро возвращать ответы на аутентификацию пользователя, это, вероятно, не защищает от несанкционированного доступа. Злоумышленник может создать серию одновременных запросов аутентификации вместо быстрой серии последовательных запросов. По крайней мере, с вашей стратегией вы знаете, что они получают только 2400 предположений в день на пользователя. Подумайте о том, чтобы отключить пользователя на более длительный период, чем 5 минут, особенно после того, как он сделает 10 или 15 предположений.

Для параноиков регистрируйте дополнительные данные с каждой неудачной попыткой, такие как IP-адрес, строка пользовательского агента и другие заголовки http в запросе. Возможно, вы сможете определить закономерности в случае реальной атаки.

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

person Domino    schedule 16.10.2014
comment
Если вы хотите прокомментировать мой ответ, сделайте это в качестве комментария под моим ответом;). - person Tymoteusz Paul; 16.10.2014
comment
И в качестве комментария к контенту, с блокировкой вы открыты для всех видов грифинга, когда злоумышленник может просто блокировать учетную запись желаемого человека снова и снова, что делает невозможным для него фактическое использование системы. И нет, ограничение по IP-адресу не поможет, поскольку заголовки могут быть подделаны, а гриферу все равно, что он не получит ответ - будет выполнено действие входа в систему, и это то, что имеет значение. - person Tymoteusz Paul; 16.10.2014
comment
Если бы StackOverflow позволил мне комментировать, я бы это сделал. К сожалению, в то время этого не произошло. - person Domino; 27.10.2014
comment
Это не означает, что вы должны засорять свой ответ комментариями, поскольку ограничения репутации существуют не просто так - чтобы новые пользователи могли сосредоточиться на предоставлении собственных ответов и вопросов, а не на комментариях. И в то же время вы могли бы ответить на мой собственный комментарий относительно вашего ответа и того, как вы предотвратите возникновение этой ситуации. - person Tymoteusz Paul; 27.10.2014
comment
В качестве комментария ко второму комментарию следует отметить, что блокировка считается допустимой стратегией безопасности и требуется многими структурами безопасности, например требованием 8.5.13 соответствия PCI. У любого метода есть свои плюсы и минусы, правда? Я бы предпочел, чтобы злоумышленник мог заблокировать только действительного человека, а не выдавать себя за него и получать доступ к сервису. Например, я бы предпочел, чтобы моя учетная запись в онлайн-банке была заблокирована, чем иметь доступ вместе с самозванцем, также имеющим доступ. - person Domino; 27.10.2014
comment
Это стандартный сценарий, когда время от времени вы будете сталкиваться с блокировкой вашей учетной записи. Но никоим образом не отвечает предложенному мною сценарию, когда виновник вызывает постоянную блокировку почти всех ваших учетных записей пользователей (которые очень легко найти в Интернете). Что ты собираешься делать тогда? Какие изменения вы внесете в систему, чтобы противостоять этому? - person Tymoteusz Paul; 27.10.2014
comment
Двухфакторная аутентификация. - person Domino; 27.10.2014
comment
Что насчет этого? Вы вдруг назначите всем людям двустороннюю аутентификацию, когда произойдет такая атака? Или вы имеете в виду, что вы не заблокируете кого-то, если он будет запрашивать неправильный пароль без действующего токена аутентификации? Если последнее, вы просто усложняете брутфорс, так как нужно угадать два пароля (при условии, что двусторонняя реализация реализована правильно, что очень часто делается очень неправильно), и вы никоим образом не предоставляете желаемый локаут против грубой силы, тем более что он будет попадать так редко, что пролетит над фильтром. - person Tymoteusz Paul; 27.10.2014
comment
Похоже, что если у вас есть первоначальный запрос / ответ, поскольку некоторые из них могут быть автоматизированы с некоторым скрытым полем CSRF, это будет сложнее для грифера. Я не думаю, что они могут подделать IP-адрес и по-прежнему получать HTTP-ответ, не раскрывая свою личность или личность какого-либо прокси, который они контролируют? - person Domino; 27.10.2014
comment
Собираетесь ли вы привязать токен CSRF к конкретному IP-адресу человека, который его запросил? Если нет - соскоблите его с реального IP, а затем отправьте запросы с фальшивых. Если вы это сделаете - будьте готовы к тому, что ваша база данных будет затоплена до тех пор, пока она не перевернется (потому что вы должны иметь неограниченное количество токенов для каждого данного IP-адреса в любой момент времени, никогда не знаешь, сколько людей разделяют один). Правильный ответ - сместить момент блокировки. Когда учетная запись подвергается атаке, вы отмечаете ее так, но не блокируете ее. Вы блокируете его при следующем успешном входе в систему, а затем запрашиваете стороннюю проверку для этой учетной записи, прежде чем она будет разблокирована. - person Tymoteusz Paul; 27.10.2014

arrow_upward
1
arrow_downward

Вот несколько вариантов:

Блокировка учетной записи

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

Проблемы:

  • Неэффективен против медленных атак, которые пытаются выполнить только несколько попыток входа в систему на относительно больших интервалах времени.
  • Злоумышленник может заблокировать множество учетных записей, считайте это DoS.
  • Злоумышленник может получить некоторую информацию о вашем сайте в зависимости от ответов об ошибках.

Блокировка IP

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

Проблемы:

  • Это может заблокировать большие группы пользователей.
  • Неэффективен против автоматических инструментов, использующих прокси.

Делайте паузы

Вы делаете паузы при проверке пароля, это замедлит атаку.

Проблемы:

  • Атака может быть многопоточной, поэтому вы примерно в той же ситуации.

Captcha

Есть хорошие алгоритмы, которые могут правильно определить эти странные формы / буквы / цифры.

Капча не эффективна на 100%, но может замедлить атаку.

Вход для определенных IP-адресов

Дайте пользователям возможность разрешить вход только с определенных IP-адресов.

  • Это не практично для каждого пользователя.

Добавьте отсутствие предсказуемого поведения

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

person JosEduSol    schedule 16.10.2014
comment
Капча НИКОГДА не была эффективна на 100%. Я не могу вспомнить время в этой проклятой жизни, когда она была эффективна даже на 50%, не говоря уже о 100%. То, что всегда было и есть, - это серьезное раздражение для законных пользователей и общая боль в спине. - person Tymoteusz Paul; 16.10.2014
comment
@Puciek Да, я полностью с тобой согласен. - person JosEduSol; 16.10.2014
comment
Как вы думаете, какое решение является лучшим? - person inf3rno; 04.11.2014
comment
@ inf3rno Привет. Я думаю, это сильно зависит от ситуации, не все атаки методом перебора одинаковы, некоторые из них более сложны, чем другие. В общем, для обычных веб-сайтов достаточно комбинации блокировки учетной записи с дросселированием запросов. Кроме того, пользователи должны использовать сложные пароли (это можно принудительно указать в форме регистрации). И всегда старайтесь раскрывать минимально важную информацию в сообщениях об ошибках, насколько это возможно. - person JosEduSol; 04.11.2014
comment
Как вы думаете, необходимо ли разрешить восстановление с помощью локаута? Как бы вы это решили, например с адресом активации? - person inf3rno; 04.11.2014
comment
@ inf3rno Что ж, это хороший момент. Может быть какой-то механизм, позволяющий повторно открывать учетные записи для законных пользователей, если это действительно необходимо или нет, я не знаю, это зависит. Есть несколько способов (некоторые более слабые, чем другие): разблокировка по времени, самостоятельная разблокировка (как вы упомянули: электронная почта (или, возможно, смс на мобильный телефон)), ручная разблокировка (работа для администратора). - person JosEduSol; 04.11.2014

arrow_upward
0
arrow_downward

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

person sumanta    schedule 16.10.2014
comment
И вы также можете реализовать капчу. - person sumanta; 16.10.2014
comment
@ user4087819 В наши дни Captcha не работает. - person ; 16.10.2014
comment
капча никогда не была хорошим способом остановить преступников. Вы должны либо сделать его настолько плохим, чтобы он был едва читаем для легальных пользователей, либо он будет взломан. - person Tymoteusz Paul; 16.10.2014
comment
Но, по крайней мере, мы можем заставить пользователя использовать сложный пароль и менять его каждые определенное время. - person sumanta; 16.10.2014
comment
@ user4087819 тьфу это становится очень оффтопом. Принуждение к сложному паролю и периодический сброс имеют рекламный эффект, который делает невозможным его запоминание. Прямой результат - рост продаж желтых стикеров. - person Tymoteusz Paul; 16.10.2014
comment
Почему ты до сих пор переписываешь комментарии? - person Shomz; 16.10.2014