Dlaczego po wprowadzeniu błędnego hasła występuje duże opóźnienie?

Dostrzegam dziwną (według mnie) rzecz dotyczącą haseł. Na przykład, jeśli wprowadzę nieprawidłowe hasło podczas logowania, nastąpi kilka sekund opóźnienia, zanim system mi o tym powie. Gdy próbuję sudoużyć niepoprawnego hasła, musiałbym również poczekać, aż powłoka powie „Przepraszam, spróbuj ponownie”.

Zastanawiam się, dlaczego tak długo „rozpoznaje się” nieprawidłowe hasło? Zostało to zaobserwowane w kilku dystrybucjach, których używam (a nawet OSX), więc myślę, że nie jest to kwestia specyficzna dla dystrybucji.

Jest to kwestia bezpieczeństwa, w rzeczywistości nie zajmuje to dużo czasu. 2 luki rozwiązuje to:

1. to ogranicza próby logowania, co oznacza, że ​​ktoś nie jest w stanie walić w system tak szybko, jak to możliwe, próbując go złamać (1M próbuje na sekundę? Nie wiem).

2. Jeśli to zrobi, gdy tylko zweryfikuje, że twoje dane uwierzytelniające są niepoprawne, możesz wykorzystać czas, jaki upłynął, aby unieważnić twoje dane uwierzytelniające, aby pomóc odgadnąć, czy część twoich danych uwierzytelniających była poprawna, znacznie skracając czas zgadywania.

Aby zapobiec tym dwóm rzeczom, system potrzebuje tylko trochę czasu, aby to zrobić, myślę, że możesz skonfigurować czas oczekiwania za pomocą PAM ( patrz odpowiedź Michaelsa ).

Inżynieria bezpieczeństwa ( 2ed, amazon | 1ed, bezpłatny ) daje znacznie lepsze wyjaśnienie tych problemów.

Jest to celowe, aby spróbować ograniczyć brutalne wymuszanie. Zwykle możesz go zmodyfikować, szukając FAIL_DELAYwpisu konfiguracji /etc/login.defsi zmieniając jego wartość (moje 3domyślnie mają sekundy), chociaż komentarz w tym pliku sprawia, że ​​brzmi to tak, jakby PAM wymusił co najmniej 2drugie opóźnienie, bez względu na wszystko

W nowoczesnych systemach Linux, pam_unix.so narzuca takie opóźnienie. Jak wcześniej informowaliśmy, to może być skonfigurowany do dwóch sekund, zmieniając FAIL_DELAYw /etc/login.defs. Jeśli chcesz jeszcze bardziej zmniejszyć opóźnienie, musisz dać pam_unix.so opcję „nodelay”. Na przykład w moim systemie, jeśli prześledzisz dołączenia zaczynając od /etc/pam.d/sudo, okaże się, że musisz edytować następujący wiersz /etc/pam.d/system-auth:

auth      required  pam_unix.so     try_first_pass nullok

i zmień to na:

auth      required  pam_unix.so     try_first_pass nullok nodelay

Niestety, sposób, w jaki moja linuksowa dystrybucja (arch) konfiguruje rzeczy, zawiera ten sam system-authplik system-remote-login, który jest używany przez sshd.

Chociaż można bezpiecznie wyeliminować opóźnienie w sudo, ponieważ jest ono rejestrowane, używane tylko przez lokalnych użytkowników i możliwe do uniknięcia przez lokalnych atakujących, prawdopodobnie nie chcesz eliminować tego opóźnienia w przypadku zdalnego logowania. Możesz to oczywiście naprawić, pisząc niestandardowe sudo, które nie tylko zawiera udostępnione pliki uwierzytelniania systemowego.

Osobiście uważam, że opóźnienie w sudo (i ignorowanie SIGINT) jest dużym błędem. Oznacza to, że użytkownicy, którzy wiedzą, że źle wpisali hasło, nie mogą zabić procesu i sfrustrować się. Oczywiście nadal możesz zatrzymać sudo za pomocą Ctrl-Z, ponieważ sudo nie łapie SIGTSTP, a po zatrzymaniu możesz go zabić za pomocą kill -9 (SIGKILL). To po prostu denerwujące. Oznacza to, że zautomatyzowany atak może wystrzelić sudo na pseudo-terminale z bardzo dużą prędkością. Ale opóźnienie to frustruje legalnych użytkowników i zachęca ich do zawieszenia swoich powłok roota zamiast wychodzenia z nich, aby uniknąć konieczności ponownego sudo.