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

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

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

— phunehehe
источник

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

— krozaine

Ответы:

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

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

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

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

— xenoterracide
источник

// оффтоп g это не ошибка, это особенность ;-)

— echox

Ваша партнерская ссылка была автоматически переписана на SE, кстати.

— Желатин

@Tshepang: см. Главу 2 , в частности §2.4 и §2.5.3.3.

— Жиль

Разница между ранним и поздним отказом при сравнении хэша пароля измеряется в наносекундах. При правильном кодировании (сравнение памяти с постоянным временем) нет никакой разницы. Это не оправдание для добавления задержки.

— CodesInChaos

Я согласен с CodesInChaos: второй пункт ответа неверен. На самом деле происходит следующее: 1. вычисляется хэш вашего ввода; 2. этот хеш сравнивается с сохраненным хешем (каждый байт, даже если разница уже была найдена); Обратите внимание, что эти два шага ни в коем случае не являются более быстрыми или медленными в зависимости от того, был ли введен правильный пароль. (и, как уже отмечали другие, добавление продолжительности сна не исправило бы временную атаку, если бы это было возможно)

— пример

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

— Михаил Мрозек
источник

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

— ксенотеррацид

Я думаю, что fail_delay также настраивается в /etc/pam.d/login. Ищитеpam_faildelay.so delay=

— Стивен Д.

что мешает вам написать оболочку для sudo, которая запускает новый экземпляр sudo, если попытка не работает в течение, скажем, 0,1 секунды?

— Янус Троелсен

В современных системах 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.

— user3188445
источник

То же самое с Fedora. Удивительный анализ

— Freedom_Ben

Блестящий ответ. Я также думал, что FAIL_DELAY устарел в современных настольных системах. Вы должны полагаться на шифрование разделов / жестких дисков и ничего больше. Как правило, нет второго пользователя, который мог бы попытаться взломать принудительный пароль root. Однако потенциально вредоносные программы могут злоупотреблять небезопасным FAIL_DELAY и, таким образом, получать root-доступ.

— phil294

установка pam-unix на nodelayустановит время ожидания на 0, и FAIL_DELAY тогда игнорируется.

— phil294

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

— Радон Росборо