Слабые стороны 3-Strike Security

Я читал некоторую литературу по безопасности, в частности по безопасности паролей / шифрованию, и мне было интересно одно: правило 3-го удара - идеальное решение для защиты паролем? То есть, если количество попыток ввода пароля ограничено небольшим числом, после которого все запросы на проверку подлинности не будут выполняться, не защитит ли это пользователей от вторжения? Я понимаю, что получение доступа или контроля над чем-то не всегда означает прохождение через систему аутентификации, но разве эта функция не делает атаки по словарю / перебором устаревшими? Я что-то пропустил?

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

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

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

• Такой подход может превратить словарную атаку в DOS-атаку на систему, предотвращающую доступ, если она реализована плохо. Например, сервер может быть залит попытками аутентификации. Одним из способов решения этой проблемы является обеспечение службы проверки подлинности для управления потоком последующих обращений к заблокированной учетной записи. Например, если учетная запись заблокирована, представьте задержку перед каждой последующей попыткой входа в систему. Однако можно было бы поместить задержку между попыткой входа в систему и «отказом в доступе», которая оставляет дверь открытой для распределенной атаки типа «отказ в обслуживании», когда злоумышленник запускает много попыток одновременной аутентификации.

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

  • Замедление запуска имен пользователей, не предоставляя информации о том, является ли имя пользователя или пароль неправильным. Это делает атаки, в которых виновник угадывает имена пользователей, более заметными для администраторов и менее эффективными.
  • Вместо блокировки учетной записи после фиксированного количества неудачных попыток, просто заблокируйте этот режим аутентификации. Другими словами, требуется, чтобы пользователь, на учетную запись которого была атакована, проходил аутентификацию с использованием другого (возможно, более сложного, но менее легко атакованного) метода. Хорошим примером является то, как телефон Android потребует от пользователя использовать свои данные для входа в Google после неудачной аутентификации с использованием шаблона разблокировки экрана или PIN-кода. Теоретически, это похоже на требование от атакованного пользователя просить разблокировать его учетную запись, однако это не требует немедленного вмешательства системного администратора.
  • Вместо блокировки учетной записи (или в дополнение к блокировке учетной записи для этого конкретного режима проверки подлинности - см. Выше) блокировка пытается выполнить проверку подлинности из того места, где происходит атака. Например, если аутентификация выполняется с помощью имени пользователя и пароля, по сети, после трех неудачных попыток аутентификации вы можете предотвратить дальнейшие попытки пользователей с того же IP-адреса или подсети войти в систему с именем пользователя или паролем. Там, где существует высокая вероятность того, что несколько пользователей (включая злоумышленника) могут использовать один и тот же IP-адрес или подсеть, вы можете просто отключить проверку подлинности по имени пользователя / паролю для IP-адреса или подсети на некоторое время, оставив более сложные методы проверки подлинности открытыми для невиновных пользователи в непосредственной близости от злоумышленника.

• Если ваш страх непреднамеренно наказывает забывчивого пользователя, как если бы он был злоумышленником, вместо того, чтобы контролировать поток неудачных попыток входа в систему после фиксированного числа неудачных попыток, вы можете использовать частоту попыток входа в систему в качестве доказательства того, что учетная запись подвергается атаке. Например, если вы видите 10 попыток аутентификации в течение секунды, вы можете использовать один из методов, описанных выше, чтобы предотвратить дальнейшие подобные попытки аутентификации. С другой стороны, вы можете использовать этот быстрый поток попыток входа в систему в качестве сигнала, чтобы начать контролировать поток. Этот метод становится все более популярным на форумах, в то время как после определенного количества неудачных попыток входа с определенного IP-адреса этот IP-адрес не может пройти аутентификацию в течение короткого периода времени.

• Наконец, хороший способ предотвратить повторное попадание пользователя в атаку DOS - дать ему / ей сбросить как пароль, так и имя пользователя . Другими словами, обрабатывайте имя пользователя и пароль как секреты. Если имя пользователя используется в другом месте (например, на форуме, если имя пользователя является отображаемым именем пользователя), просто воспринимайте это отображаемое имя как нечто отдельное. Этот подход обычно используется социальными сетями, где имя пользователя, используемое при аутентификации, является адресом электронной почты - что-то, что может быть изменено, но редко используется совместно, в то время как отображаемое имя, используемое на сайте, является определенным пользователем, которое может или не может быть быть изменен.

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