it-swarm-ru.tech

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

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

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

93
phunehehe

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

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

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

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

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

94
xenoterracide

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

42
Michael Mrozek

В современных системах 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 дистрибутив (Arch) настраивает то же самое system-auth файл включается system-remote-login, который используется sshd.

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

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

12
user3188445