Почему там большая задержка после ввода неправильного пароля?
FreeBSD является операционной системой. Linux является ядром. Таким образом в Вашем вопросе Вы сравниваете яблоки и оранжевые семена.
Лицензирование и поддержка устройства было бы моими двумя главными причинами, почему кто-то выберет один по другому
Это - вещь безопасности, на самом деле не занимает много времени понимать это. 2 уязвимости это решает:
это регулирует попытки входа в систему, означая, что кто-то не может загнать систему с такой скоростью, как она может пойти, пытаясь расколоться, это (1M делает попытку секунды? Я не знаю).
Если бы это сделало это, как только это проверило, что Ваши учетные данные были неправильными, Вы могли использовать количество времени, которое это заняло, чтобы это делало недействительным Ваши учетные данные, чтобы помочь предположить, была ли часть Ваших учетных данных корректна, существенно уменьшив время предположения.
для предотвращения этих 2 вещей, система просто берет определенное количество времени, чтобы сделать это, я думаю, что можно настроить время ожидания с PAM (См., что Michaels отвечает).
Разработка безопасности (2ed, амазонка | 1ed, свободный) дает намного лучшее объяснение этих проблем.
-
1//offtopic g не ошибка, это - функция ;-) – echox 16.09.2010, 11:18
-
2Ваша партнерская ссылка была автоматически переписана к SE's, btw. – Gelatin 18.09.2010, 23:50
-
3@Tshepang: См. главу 2, особенно §2.4 и §2.5.3.3. – Gilles 'SO- stop being evil' 01.12.2010, 20:42
-
4Различие между ранним и последним отказом при сравнении хэша пароля измеряется в наносекундах. С надлежащим кодированием (постоянное сравнение памяти времени) нет никакого различия вообще. Это не выравнивание для добавления задержки. – CodesInChaos 23.03.2013, 10:50
-
5я соглашаюсь с CodesInChaos: вторая точка ответа является неправильной. То, что на самом деле происходит, следующее: 1. хеш Вашего входа вычисляется; 2. тот хеш сравнивается с сохраненным хешем (каждый байт его, даже если различие было уже найдено); Заметьте, что эти два шага никоим образом не быстрее или медленнее в зависимости от того, был ли пароль, который Вы ввели, правильным. (и поскольку другие уже указали, добавив, что продолжительность сна не зафиксировала бы атаку временным анализом, если бы это было возможно) – example 20.07.2015, 12:35
Это является намеренным, чтобы попытаться ограничить грубое принуждение. Можно обычно изменять его путем поиска FAIL_DELAY запись конфигурации в /etc/login.defs и изменение его значения (мое 3 секунды по умолчанию), хотя комментарий в том файле заставляет его походить на PAM, осуществит, по крайней мере, a 2 вторая задержка независимо от того, что
-
1, Это должно предотвратить больше, чем просто грубое принуждение. но бонусные очки для знания, где настроить его. – xenoterracide 16.09.2010, 08:33
-
2я думаю, что fail_delay также настраивается в
/etc/pam.d/login. Искатьpam_faildelay.so delay=– Steven D 16.09.2010, 08:40 -
3, что препятствует тому, чтобы Вы писали обертку для sudo, который запускает новый sudo экземпляр однажды попытка, не работает в, скажем, 0.1 secs? – Janus Troelsen 20.11.2014, 18:35
-
4, что препятствует тому, чтобы Вы писали обертку для sudo, который запускает новый sudo экземпляр однажды попытка, не работает в, скажем, 0.1 secs? – Janus Troelsen 20.11.2014, 18:35
В современных системах 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, который не просто включает общие файлы system-auth.
Лично я считаю задержку sudo (и игнорирование SIGINT) большой ошибкой. Это означает, что пользователи, которые знают, что они ошиблись при вводе пароля, не могут остановить процесс и расстроиться. Конечно, вы все равно можете остановить sudo с помощью Ctrl-Z, поскольку sudo не перехватывает SIGTSTP, и после его остановки вы можете убить его с помощью kill -9 (SIGKILL). Это просто раздражает.Это означает, что автоматическая атака может запускать судо на псевдотерминалах со сверхвысокой скоростью. Но задержка расстраивает законных пользователей и побуждает их приостановить свои корневые оболочки вместо того, чтобы выходить из них, чтобы избежать повторного использования sudo.