Почему проверка неправильного пароля занимает больше времени, чем проверка правильного?

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

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

Я заметил это во всем дистрибутивы Linux Я когда-либо пробовал.

12 ответов


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

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

последнее особенно важно. Значит нет полезные сообщения, такие как:

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

или:

Sorry, password wasn't long enough

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

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

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


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


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

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


в основном, чтобы смягчить грубую силу и атаки словаря.

С руководство разработчика приложений 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_...() вызов возвращать ошибку. Желательно там также будет пауза перед приложение продолжает. Принципал причиной такой задержки является обеспечение: промедление препятствует применению грубой силы словарь атакует в первую очередь, но и помогает помешать timed (скрытый канал) атаки.


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

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

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


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

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

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

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

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


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

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


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

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

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

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

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


на Ubuntu 9.10, и я думаю, что новые версии тоже, файл, который вы ищете, находится на

/ etc / pam.д/логин

редактировать строку:

auth необязательный pam_faildelay.так что задержка=3000000

изменить номер 3 с другим вы можете.

обратите внимание, что для аутентификации "nodelay", я думаю, вы должны отредактировать файл

/ etc / pam.д/общие-авт

тоже. На линии:

auth [success=1 по умолчанию=игнорировать] pam_unix.так nullok_secure

добавить 'nodelay' в финал (без кавычек). Но окончательного объяснения о nodelay-это то, что я думаю.


Я хотел бы добавить примечание с точки зрения разработчиков. Хотя это не было бы очевидно невооруженным глазом, умный разработчик вырвался бы из запроса соответствия, когда матч найден. В witness успешный матч будет завершен быстрее, чем неудачный матч. Потому что функция сопоставления будет сравнивать учетные данные со всеми известными учетными записями, пока не найдет правильное соответствие. Другими словами, допустим, есть 1 000 000 учетных записей пользователей в порядке по IDs; 001, 002, 003 и так далее. Ваш ID 43,001. Итак, когда вы вводите правильное имя пользователя и пароль, сканирование останавливается на 43,001 и регистрирует вас. Если учетные данные неверны, то он сканирует все 1000000 записей. Разница во времени обработки на двухъядерном сервере может составлять миллисекунды. В Windows Vista с 5 учетными записями пользователей это будет в наносекундах.


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


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

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

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

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

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

линеаризации.Ява.

линеаризации.docx, образец вывода

серийный номер составляет четыре символа длиной ans каждый символ имеет 128 возможное значение. тогда есть 1284 = 228 = 268,435,456 возможных сериалов. Если злоумышленник должен случайным образом угадать полные серийные номера, она угадает серийный номер в о 227 = 134,217,728 попыток, что является огромным объемом работы. С другой стороны, используя атаку линеаризации выше, an в среднем для каждой буквы требуется только 128/2 = 64 догадки, для общей сумме ожидаемая работа около 4 * 64 = 28 = 256 догадки, это тривиальный объем работы.

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