Почему проверка неправильного пароля занимает больше времени, чем проверка правильного? - PullRequest
81 голосов
/ 03 апреля 2009

Этот вопрос всегда беспокоил меня.

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

Я наблюдал это во всех дистрибутивах Linux Я когда-либо пробовал.

Ответы [ 12 ]

105 голосов
/ 03 апреля 2009

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

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

Последний особенно важен. Это означает, что нет полезных сообщений, таких как:

Your user name is correct but your password is wrong, please try again

или

Sorry, password wasn't long enough

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

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

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

14 голосов
/ 03 апреля 2009

Это займет больше времени, чтобы угадать пароли.

12 голосов
/ 03 апреля 2009

В основном для защиты от переборов и атак по словарю.

С Руководство разработчика приложений Linux-PAM :

Планирование задержек

extern int pam_fail_delay(pam_handle_t *pamh, unsigned int micro_sec);

Эта функция предлагается Linux-PAM чтобы облегчить задержки после не удалось вызвать pam_authenticate () и до того, как контроль возвращается приложение. При использовании этой функции разработчик приложения должен проверьте, доступен ли он с,

#ifdef PAM_FAIL_DELAY
    ....
#endif /* PAM_FAIL_DELAY */

Обычно запросы приложений что пользователь аутентифицирован Linux-PAM через звонок в pam_authenticate () или pam_chauthtok (). Эти функции вызывают каждый из Сложенные модули аутентификации перечислены в соответствующем Linux-PAM конфигурационный файл. По указанию этот файл, один из нескольких модулей может произойти сбой, вызвав вызов pam _... () вернуть ошибку. Желательно для там также должна быть пауза перед Приложение продолжается. Основной Причиной такой задержки является безопасность: задержка действует, чтобы препятствовать грубой силе словарные атаки в первую очередь, но также помогает мешать по времени (скрытый канал) атаки.

12 голосов
/ 03 апреля 2009

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

Даже попытка ввести несколько паролей - даты рождения, имя кота и тому подобное - превращается не в веселье.

8 голосов
/ 03 апреля 2009

Это очень простой, практически легкий способ значительно повысить безопасность. Рассмотрим:

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

  2. Система B генерирует 5-секундную задержку после каждого неверного предположения. Эффективность атакующего была снижена до 12 попыток в минуту, что эффективно наносит урон грубой атаке. Вместо часов, это может занять месяцы, чтобы найти действительный логин. Если бы хакеры были таким пациентом, они бы действовали законно. : -)

4 голосов
/ 03 апреля 2009

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

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

В GDM задержка устанавливается в файле gdm.conf (обычно в /etc/gdm/gdm.conf). вам нужно установить RetryDelay = x, где x - значение в секундах.

Большинство дистрибутивов linux в настоящее время также поддерживают определение FAIL_DELAY в /etc/login.defs, позволяющее вам установить время ожидания после неудачной попытки входа в систему.

Наконец, PAM также позволяет вам установить атрибут nodelay в строке аутентификации, чтобы обойти задержку сбоя. ( Вот статья о PAM и Linux )

1 голос
/ 05 июля 2010

То, что я пробовал раньше, казалось, работало, но на самом деле это не так; если вам нужно, вы должны просмотреть историю редактирования вики ...

Что работает (для меня) в том, чтобы оба снизить значение pam_faildelay.so delay = X в / etc / pam.d / login (Я уменьшил его до 500000, полсекунды), , а также добавляем нодлеев (с пробелом) к концу строки в common-auth , как описано Габриэлем в своем ответе.

auth [success=1 default=ignore] pam_unix.so nullok_secure nodelay

По крайней мере для меня (debian sid), только внесение одного из этих изменений не приведет к значительному сокращению задержки ниже 3 секунд по умолчанию, хотя можно удлинить задержку, только изменив значение в /etc/pam.d /login.

Этого дерьма достаточно, чтобы заставить взрослого человека плакать!

1 голос
/ 03 апреля 2009

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

Если ответ на правильный пароль является (какое-то значение) немедленным, разве вам не нужно ждать, пока это значение не станет больше, чтобы узнать, что пароль неверен? (по крайней мере, знать вероятностно, что хорошо для взлома) И в любом случае вы будете проводить эту атаку параллельно ... это все один большой приветственный коврик DoS?

0 голосов
/ 21 мая 2015

Технически, эта преднамеренная задержка предназначена для предотвращения атак, таких как "Линеаризационная атака" (есть и другие атаки и причины) .

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

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

  • Итак, злоумышленник может выбрать четырехсимвольную строку и строка, начинающаяся с x , займет больше всего времени. (по догадкам)
  • Атакующий может затем исправить символ как x и изменить второй символ, и в этом случае он обнаружит, что y занимает самое длинное.
  • Атакующий может затем исправить первые два символа как xy и изменить третий символ, и в этом случае он обнаружит, что b берет длинный.
  • Атакующий может затем исправить первые три символа как xyb и изменить четвертый символ, и в этом случае они обнаружат, что a берет длинный.

Следовательно, злоумышленники могут восстановить серийный символ по одному за раз.

Linearization.java.

Linearization.docx, пример вывода

Серийный номер состоит из четырех символов и каждого символа имеет 128 возможные значения. Тогда есть 128 4 = 2 28 = 268 435 456 возможных сериалов . Если злоумышленник должен случайно угадать полные серийные номера, она будет угадывать серийный номер примерно в 2 27 = 134 217 728 попыток, что является огромным трудом . С другой стороны, используя вышеописанную атаку линеаризации, в среднем только 128/2 = 64 догадки требуется для каждой буквы, для Всего Ожидаемая работа около 4 * 64 = 2 8 = 256 догадок, что является тривиальным объемом работы.

Большая часть письменного военного материала взята из этого (взято из «Информационной безопасности: принципы и практика» Марка Стэмпа). Кроме того, приведенные выше расчеты не учитывают количество догадок, необходимых для определения правильной серийной длины.

0 голосов
/ 25 августа 2011

Я согласен. Это произвольное решение для программирования. Установка задержки на одну секунду вместо трех на самом деле не повредит взлому пароля, но делает его более удобным для пользователя.

...