Dlaczego sprawdzenie nieprawidłowego hasła powinno zająć więcej czasu niż sprawdzenie właściwego?

To pytanie zawsze mnie niepokoiło.

W systemie Linux, gdy zostaniesz zapytany o hasło, czy wprowadzone dane są poprawne, sprawdza od razu, prawie bez opóźnienia. Ale z drugiej strony, jeśli wpiszesz nieprawidłowe hasło, sprawdzenie zajmie więcej czasu. Dlaczego?

Zauważyłem to we wszystkich dystrybucjach Linuksa , jakie kiedykolwiek próbowałem.

W rzeczywistości ma to na celu zapobieganie atakom brutalnej siły przed próbowaniem milionów haseł na sekundę. Chodzi o to, aby ograniczyć szybkość sprawdzania haseł i istnieje szereg zasad, których należy przestrzegać.

• Udana para użytkownik / hasło powinna natychmiast zakończyć się sukcesem.
• Nie powinno być żadnego dostrzegalna różnica w przyczynach awarii, które mogą zostać wykryte.

Ten ostatni jest szczególnie ważny. Oznacza to brak pomocnych wiadomości, takich jak:

Your user name is correct but your password is wrong, please try again

lub:

Sorry, password wasn't long enough

Ani nawet różnicy w czasie odpowiedzi między przyczynami niepowodzenia „nieprawidłowego użytkownika i hasła” i „prawidłowego użytkownika, ale nieprawidłowego hasła”.

Każda awaria powinna zawierać dokładnie te same informacje, tekstowe i inne.

Niektóre systemy idą jeszcze dalej, zwiększając opóźnienie z każdą awarią lub zezwalając tylko na trzy awarie, a następnie mają ogromne opóźnienie, zanim pozwolą na ponowną próbę.

To sprawia, że ​​odgadywanie haseł trwa dłużej.

Nie jestem pewien, ale dość często integruje się opóźnienie po wprowadzeniu nieprawidłowego hasła, aby utrudnić ataki. To sprawia, że ​​atak jest praktycznie niewykonalny, ponieważ sprawdzenie tylko kilku haseł zajmie dużo czasu.

Nawet wypróbowanie kilku haseł - dat urodzenia, imienia kota i tym podobnych - nie jest zabawne.

Zasadniczo w celu złagodzenia ataków brutalnej siły i ataków słownikowych.

Z Przewodnika programisty aplikacji Linux-PAM :

Planowanie opóźnień

extern int pam_fail_delay(pam_handle_t *pamh, unsigned int micro_sec);

Ta funkcja jest oferowana przez Linux-PAM w celu ułatwienia opóźnień czasowych po nieudanym wywołaniu pam_authenticate () i przed zwróceniem kontroli do aplikacji. Korzystając z tej funkcji programista aplikacji powinien sprawdzić, czy jest ona dostępna za pomocą,

#ifdef PAM_FAIL_DELAY
    ....
#endif /* PAM_FAIL_DELAY */

Generalnie aplikacja żąda uwierzytelnienia użytkownika przez Linux-PAM poprzez wywołanie pam_authenticate () lub pam_chauthtok (). Te funkcje wywołują każdy ze stosowych modułów uwierzytelniania wymienionych w odpowiednim pliku konfiguracyjnym Linux-PAM. Zgodnie z zaleceniami tego pliku, jeden lub więcej modułów może zawieść, powodując, że wywołanie pam _... () zwróci błąd. Pożądane jest, aby była również przerwa przed kontynuowaniem aplikacji. Głównym powodem takiego opóźnienia jest bezpieczeństwo: opóźnienie działa przede wszystkim w celu zniechęcenia do ataków słownikowych brutalnej siły, ale także pomaga utrudnić ataki czasowe (ukryty kanał).

To bardzo prosty, praktycznie łatwy sposób na znaczne zwiększenie bezpieczeństwa. Rozważać:

1. System Anie ma opóźnienia. Osoba atakująca ma program, który tworzy kombinacje nazwy użytkownika i hasła. Przy liczbie tysięcy prób na minutę wypróbowanie każdej kombinacji i zarejestrowanie wszystkich udanych logowań zajmuje tylko kilka godzin.

2. System Bgeneruje 5-sekundowe opóźnienie po każdym nieprawidłowym zgadnięciu. Skuteczność atakującego została zmniejszona do 12 prób na minutę, skutecznie paraliżując brutalny atak. Znalezienie prawidłowego loginu może zająć miesiące zamiast godzin. Gdyby hakerzy byli tak cierpliwi, byliby legalni. :-)

Opóźnienia nieudanego uwierzytelnienia mają na celu zmniejszenie liczby prób logowania. Pomysł, że jeśli ktoś próbuje użyć słownika lub ataku brutalnej siły na jedno lub może konta użytkowników, osoba atakująca będzie musiała poczekać na opóźnienie błędu, co zmusi go do poświęcenia więcej czasu i da ci większą szansę na wykrycie tego.

Możesz również chcieć wiedzieć, że w zależności od tego, czego używasz jako powłoki logowania, zwykle istnieje sposób skonfigurowania tego opóźnienia.

W GDM opóźnienie jest ustawiane w pliku gdm.conf (zwykle w /etc/gdm/gdm.conf). musisz ustawić RetryDelay = x, gdzie x jest wartością w sekundach.

Większość dystrybucji Linuksa w dzisiejszych czasach obsługuje również zdefiniowanie FAIL_DELAY w /etc/login.defs, co pozwala ustawić czas oczekiwania po nieudanej próbie logowania.

Wreszcie, PAM umożliwia również ustawienie atrybutu nodelay w linii autoryzacji, aby ominąć opóźnienie błędu. ( Oto artykuł o PAM i Linuksie )

Nie sądzę, by było to tak proste, jak sugerują odpowiedzi.

Jeśli odpowiedź na poprawne hasło jest (pewna wartość) natychmiastowa, czy nie musisz tylko czekać dłużej niż ta wartość, aby wiedzieć, że hasło jest nieprawidłowe? (przynajmniej wiem z prawdopodobieństwa, co jest dobre do łamania zabezpieczeń) I w każdym razie prowadziłbyś ten atak równolegle ... czy to wszystko jest jedna duża mata powitalna DoS?

To, co próbowałem wcześniej, okazało się skuteczne, ale w rzeczywistości nie; jeśli ci zależy, musisz przejrzeć historię edycji wiki ...

Co robi pracę (dla mnie) jest, aby zarówno obniżyć wartość pam_faildelay.so opóźnienia = X w /etc/pam.d/login (Spuściłem go do 500000, pół sekundy), a także dodać nodelay (poprzedzone space) do końca wiersza w common-auth , zgodnie z opisem Gabriela w swojej odpowiedzi.

auth [success=1 default=ignore] pam_unix.so nullok_secure nodelay

Przynajmniej dla mnie (debian sid), tylko jedna z tych zmian nie skróci opóźnienia znacznie poniżej domyślnych 3 sekund, chociaż możliwe jest wydłużenie opóźnienia tylko poprzez zmianę wartości w /etc/pam.d/login.

Takie gówno wystarczy, żeby dorosły mężczyzna zaczął płakać!

W systemie Ubuntu 9.10 i myślę, że w nowych wersjach znajduje się plik, którego szukasz

/etc/pam.d/login

edytuj linię:

auth opcjonalne pam_faildelay.so delay = 3000000

zmiana cyfry 3 na inną, którą chcesz.

Zauważ, że aby mieć uwierzytelnianie „nodelay”, MYŚLĘ, że powinieneś edytować plik

/etc/pam.d/common-auth

także. Na linii:

auth [success = 1 default = ignore] pam_unix.so nullok_secure

dodaj „nodelay” do końca (bez cudzysłowów). Myślę jednak, że to ostateczne wyjaśnienie dotyczące „zwłoki”.

Chciałbym dodać uwagę z punktu widzenia programistów. Chociaż nie byłoby to oczywiste gołym okiem, sprytny programista wyłamałby się z zapytania dopasowującego po znalezieniu dopasowania. Na przykład udany mecz zakończyłby się szybciej niż nieudany mecz. Ponieważ funkcja dopasowywania porówna dane uwierzytelniające ze wszystkimi znanymi kontami, dopóki nie znajdzie odpowiedniego dopasowania. Innymi słowy, powiedzmy, że istnieje 1 000 000 kont użytkowników uporządkowanych według identyfikatorów; 001, 002, 003 i tak dalej. Twój dowód tożsamości to 43 001. Tak więc, jeśli podasz poprawną nazwę użytkownika i hasło, skanowanie zatrzyma się na 43 001 i zaloguje Cię. Jeśli twoje dane uwierzytelniające są nieprawidłowe, skanuje wszystkie 1 000 000 rekordów. Różnica w czasie przetwarzania na serwerze dwurdzeniowym może być wyrażona w milisekundach. W systemie Windows Vista z 5 kontami użytkowników będzie to w nanosekundach.

Zgadzam się. To jest arbitralna decyzja programowa. Ustawienie opóźnienia na jedną sekundę zamiast trzech nie szkodzi tak naprawdę podatności na złamanie hasła, ale czyni je bardziej przyjaznym dla użytkownika.

Technicznie rzecz biorąc, to celowe opóźnienie ma na celu zapobieganie atakom takim jak „atak linearyzacji” (są też inne ataki i powody) .

Aby zilustrować atak, rozważmy program (bez tego celowego opóźnienia), który sprawdza wprowadzony numer seryjny, aby zobaczyć, czy pasuje on do prawidłowego numeru seryjnego, którym w tym przypadku jest „ xyba ” . Dla wydajności programista zdecydował się sprawdzać po jednym znaku na raz i kończyć pracę, gdy tylko zostanie znaleziony nieprawidłowy znak, przed rozpoczęciem sprawdzane są również długości.

Przetwarzanie prawidłowej długości seryjnej zajmie więcej czasu niż przetwarzanie nieprawidłowej długości seryjnej. Co więcej (dla atakującego) numer seryjny, który ma poprawny pierwszy znak, potrwa dłużej niż numer, który ma nieprawidłowy pierwszy znak. Kolejne kroki w czasie oczekiwania wynikają z tego, że za każdym razem, gdy jest jeszcze jedna pętla, porównanie, które należy wykonać przy prawidłowym wejściu.

• Zatem atakujący może wybrać czteroznakowy ciąg i ten ciąg rozpoczynający się od x zajmuje najwięcej czasu. (zgadywanie)
• Atakujący może wtedy naprawić znak jako x i zmienić drugi znak, w takim przypadku to znajdzie y trwa najdłużej.
• Atakujący może wtedy ustawić pierwsze dwa znaki jako xy i zmienić trzeci znak, w którym to przypadku znajdzie b trwa najdłużej.
• Atakujący może wtedy ustawić pierwsze trzy znaki jako xyb i zmienić czwarty znak, w takim przypadku stwierdzą, że a trwa najdłużej.

W związku z tym napastnicy mogą odzyskać seryjny jeden znak na raz.

Linearization.java.

Linearization.docx, przykładowe wyjście

Numer seryjny składa się z czterech znaków, a każdy znak ma 128 możliwych wartości. Wtedy jest 128 ⁴ = 2 ²⁸ = 268 435 456 możliwych numerów seryjnych . Gdyby atakujący musiał przypadkowo odgadnąć pełne numery seryjne, odgadłby numer seryjny w około 2 ²⁷ = 134 217 728 prób, co jest ogromnym nakładem pracy . Z drugiej strony, używając powyższego ataku linearyzacji, średnio tylko 128/2 = 64 domysłów jest wymaganych dla każdej litery, co daje całkowitą oczekiwaną pracę około 4 * 64 = 2 ⁸ = 256 domysłów, co jest kwotą trywialną pracy.

Znaczna część pisemnego tekstu wojennego jest zaadaptowana z tego (zaczerpniętego z książki Marka Stampa „Information Security: Principles and Practice”). Również powyższe obliczenia nie uwzględniają ilości domysłów potrzebnych do ustalenia prawidłowej długości seryjnej.