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

Я замечаю странную (ну, по моему мнению) вещь о паролях. Например, если я введу неверный пароль во время входа в систему, то система выдаст мне несколько секунд задержки. Когда я пытаюсь sudoввести неверный пароль, мне также придется подождать, пока оболочка не скажет: «Извините, попробуйте еще раз».

Интересно, почему так долго «распознают» неверный пароль? Это было замечено в нескольких дистрибутивах, которые я использую (и даже в OSX), поэтому я думаю, что это не специфичная для дистрибутива вещь.

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

1. это ограничивает попытки входа в систему, а это означает, что кто-то не может взломать систему так же быстро, как он может попытаться взломать ее (1M попыток в секунду? Я не знаю).

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

Чтобы предотвратить эти две вещи, системе требуется определенное время, я думаю, вы можете настроить время ожидания с помощью PAM ( см. ответ Майклса ).

Проектирование безопасности ( 2ed, amazon | 1ed, free ) дает гораздо лучшее объяснение этих проблем.

Это намеренно, чтобы попытаться ограничить грубое принуждение. Обычно вы можете изменить его, отыскивая FAIL_DELAYвход в конфигурацию /etc/login.defsи меняя его значение ( 3по умолчанию это секунды), хотя комментарий в этом файле звучит так, как будто PAM установит как минимум 2вторую задержку, независимо от того, что

В современных системах Linux причина в том, что pam_unix.so налагает такую ​​задержку. Как ранее сообщалось, это может быть сконфигурировано до двух секунд, изменяя FAIL_DELAYв /etc/login.defs. Если вы хотите еще больше уменьшить задержку, вы должны предоставить pam_unix.so опцию "nodelay". Например, в моей системе, если вы отслеживаете включения, начиная с /etc/pam.d/sudo, вы обнаружите, что должны отредактировать следующую строку /etc/pam.d/system-auth:

auth      required  pam_unix.so     try_first_pass nullok

и измените это на это:

auth      required  pam_unix.so     try_first_pass nullok nodelay

К сожалению, способ, которым мой linux distro (arch) настраивает вещи, в которые system-authвключается тот же самый файл system-remote-login, который используется sshd.

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

Лично я считаю, что задержка в sudo (и игнорирование SIGINT) является большой ошибкой. Это означает, что пользователи, которые знают, что набрали неверный пароль, не могут остановить процесс и разочароваться. Конечно, вы все равно можете остановить sudo с помощью Ctrl-Z, так как sudo не перехватывает SIGTSTP, и после его остановки вы можете убить его с помощью kill -9 (SIGKILL). Это просто раздражает. Это означает, что автоматическая атака может запускать sudos на псевдотерминалах с очень высокой скоростью. Но задержка расстраивает законных пользователей и побуждает их приостанавливать свои корневые оболочки вместо выхода из них, чтобы избежать необходимости повторного запуска sudo.