Jaka jest najlepsza metoda przeciwdziałania Brute Force?

Kilka prostych kroków:

Czarna lista niektórych wspólnych nazw użytkowników, i używać ich jako honeypot. Admin, gość itp... Nie pozwól nikomu tworzyć kont z tymi nazwami, więc jeśli ktoś próbuje je zalogować, wiesz, że ktoś robi coś, czego nie powinien.

Upewnij się, że każdy, kto ma realną władzę na stronie, ma bezpieczne hasło. Wymagaj od administratorów / moderatorów posiadania dłuższych haseł z mieszanką liter, cyfr i symboli. Odrzucaj banalnie proste hasła od zwykłych Użytkowników z wyjaśnieniem.

Jedną z najprostszych rzeczy, które możesz zrobić, to powiedzieć ludziom, kiedy ktoś próbował zalogować się na ich konto, i dać im link do zgłoszenia incydentu, jeśli to nie oni. Prosta wiadomość, gdy się logują, jak "ktoś próbował zalogować się na twoje konto o 4:20 W środę bla bla. / Align = "left" / "Pozwala na prowadzenie statystyk dotyczących ataków. Możesz zwiększyć środki monitorowania i bezpieczeństwa, jeśli zauważysz nagły wzrost liczby oszustw dostęp.

Jeśli dobrze rozumiem działanie ataków brute force, wtedy jedna lub więcej nazw użytkowników jest próbowana w sposób ciągły.

Są dwie propozycje, których chyba jeszcze tu nie widziałem:

• Zawsze myślałem, że standardową praktyką było mieć krótkie opóźnienie (sekundę lub więcej) po każdym błędnym logowaniu dla każdego użytkownika. To odstrasza brutalną siłę, ale nie wiem, jak długo jedno-sekundowe opóźnienie utrzyma atak słownikowy w ryzach. (słownik 10 000 słów = = 10 000 sekund == około 3 godzin. Hmm. To nie wystarczy.)
• zamiast spowolnić całą witrynę, dlaczego nie przepustnica nazwy użytkownika. Przepustnica staje się coraz ostrzejsza z każdą błędną próbą (do limitu, tak myślę, że prawdziwy użytkownik może się zalogować)

Edit : W odpowiedzi na komentarze dotyczące przepustnicy nazwy użytkownika: jest to przepustnica specyficzna dla nazwy użytkownika bez względu na źródło ataku.

Jeśli nazwa użytkownika jest dławiona, to nawet skoordynowany atak użytkownika (multi IP, single domyślam się na IP, ta sama nazwa użytkownika) zostałaby złapana. Poszczególne nazwy użytkowników są chronione przez przepustnicę, nawet jeśli atakujący mogą swobodnie wypróbować innego użytkownika / przepustkę w czasie limitu czasu.

Z punktu widzenia atakujących, w czasie limitu czasu możesz po raz pierwszy odgadnąć 100 haseł i szybko odkryć jedno błędne hasło na konto. W tym samym okresie możesz tylko zgadywać 50 sekund.

Z punktu widzenia konta użytkownika, to nadal trwa to samo średnia liczba domysłów złamania hasła, nawet jeśli domysły pochodzą z wielu źródeł.

Dla atakujących, w najlepszym przypadku, będzie to taki sam wysiłek, aby złamać 100 kont, jak byłoby to 1 konto, ale ponieważ nie dławisz na całej stronie, możesz dość szybko przyspieszyć przepustnicę.

Dodatkowe udoskonalenia:

• wykrywanie adresów IP, które zgadują wiele kont-408 limit czasu żądania
• wykrywanie adresów IP, które zgadują to samo konto - 408 Request Timeout po dużej (powiedzmy 100) liczbie zgadnięć.

Pomysły UI (mogą nie być odpowiednie w tym kontekście), które mogą również udoskonalić powyższe:

• Jeśli masz kontrolę nad ustawieniem hasła, pokazanie użytkownikowi jak silne jest jego hasło zachęca go do wybrania lepszego.
• jeśli kontrolujesz stronę logowania , po małej (powiedzmy 10) liczbie zgadnięć pojedynczej nazwy użytkownika, zaproponuj CAPTCHA.

Istnieją trzy czynniki uwierzytelniania:

1. Użytkownik zna coś (czyli hasło)
2. UżytkownikmA coś (czyli brelok)
3. a user is something (ie, retina scan)

Zazwyczaj strony internetowe egzekwują tylko Politykę # 1. Nawet większość banków egzekwuje tylko Politykę 1. Zamiast tego polegają na podejściu "wie coś innego" do uwierzytelniania dwuskładnikowego. (Czyli: użytkownik zna swoje hasło i nazwisko panieńskie matki.) Jeśli jesteś w stanie, sposób dodania drugiego czynnika uwierzytelniania nie jest zbyt trudny.

Jeśli możesz wygenerować około 256 znaków losowości, możesz utworzyć to w tabeli 16×16, a następnie poprosić Użytkownika o podanie wartości w tabeli komórki a-14, na przykład. Gdy użytkownik zarejestruje się lub zmieni hasło, przekaż mu tabelę i powiedz mu, aby ją wydrukował i zapisał.

Trudność z tym podejściem polega na tym, że gdy użytkownik zapomni hasła, tak jak chce, nie można po prostu zaproponuj standard "odpowiedz na to pytanie i wpisz nowe hasło", ponieważ jest to również podatne na brute-force. Ponadto nie można go zresetować i wysłać im nowego e-maila, ponieważ ich e-mail może również zostać naruszony. (Zobacz: Makeuseof.com i ich skradzionej domeny.)

Inny pomysł (który dotyczy kociąt), to to, co Boa nazywa SiteKey (wierzę, że znakami towarowymi nazwy). Krótko mówiąc, użytkownik musi przesłać obraz podczas rejestracji, a gdy próbuje się zalogować, poproś go o wybranie swojego obraz z 8 lub 15 (lub więcej) losowych. JeĹ "li wiÄ ™ c uĺľytkownik wĹ' aduje zdjÄ ™ cie swojego kotka, teoretycznie tylko on wie dokĹ ' adnie ktĂłre zdjÄ ™ cie jest jego ze wszystkich innych kociÄ ... t (czy kwiatĂłw czy czegokolwiek). Jedynym prawdziwym vunerability to podejście ma jest man-in-the-middle attack.

Jeszcze jeden pomysł (bez kittów), to śledzenie adresów IP, z którymi użytkownicy uzyskują dostęp do systemu i wymaganie od nich dodatkowego uwierzytelniania (captcha , wybierz kitty, wybierz klucz z tej tabeli), gdy logują się z adresu, którego wcześniej nie mieli. Ponadto, podobnie jak GMail, pozwala użytkownikowi zobaczyć, gdzie ostatnio się zalogował.

Edit, New Idea:

Innym sposobem walidacji prób logowania jest sprawdzenie, czy użytkownik pochodzi z twojej strony logowania. Nie możesz sprawdzić polecających, ponieważ mogą być łatwo sfałszowane. Musisz ustawić klucz w var _SESSION, gdy użytkownik wyświetli stronę logowania, a następnie sprawdzić, czy klucz istnieje, gdy przesyła swój dane logowania. Jeśli bot nie zgłosi się ze strony logowania, nie będzie mógł się zalogować. Możesz to również ułatwić, angażując javascript w ten proces, używając go do Ustawienia pliku cookie lub dodając pewne informacje do formularza po jego załadowaniu. Możesz też podzielić formularz na dwa różne przesłania (tj. użytkownik wprowadza swoją nazwę użytkownika, przesyła, a następnie na nowej stronie wprowadza swoje hasło i przesyła ponownie.)

Klucz, w tym przypadku, jest najważniejszym aspektem. Często metoda ich generowania polega na połączeniu danych Użytkownika, jego IP i czasu ich przesłania.

Muszę zapytać, czy przeprowadziłeś analizę kosztów i korzyści tego problemu; brzmi to tak, jakbyś próbował chronić się przed atakującym, który ma wystarczająco dużo obecności w sieci, aby odgadnąć liczbę haseł, wysyłając może 3-5 żądań na IP(ponieważ odrzuciłeś Dławienie IP). Ile (mniej więcej) kosztowałby taki atak? Czy jest to droższe niż wartość kont, które próbujesz chronić? Ile gigantycznych botnetów chce tego, co masz?

Odpowiedź może być nie -- ale jeśli tak, mam nadzieję, że otrzymujesz pomoc od jakiegoś specjalisty ds. bezpieczeństwa; umiejętności programistyczne (i wynik StackOverflow) nie są silnie skorelowane z wiedzą na temat bezpieczeństwa.

Wcześniej odpowiedziałem na bardzo podobne pytanie w Jak mogę ograniczyć próby logowania użytkowników w PHP . Powtórzę proponowane rozwiązanie tutaj, ponieważ wierzę, że wielu z was uzna to za Pouczające i użyteczne, aby zobaczyć jakiś rzeczywisty kod. Należy pamiętać, że używanie CAPTCHA może nie być najlepszym rozwiązaniem ze względu na coraz dokładniejsze algorytmy używane w captcha busters obecnie: {]}

Nie można po prostu zapobiec atakom DoS poprzez łańcuchowe Dławienie do pojedynczy adres IP lub nazwa użytkownika. Do diabła, nie można nawet zapobiec próbom szybkiego logowania przy użyciu tej metody.

dlaczego? ponieważ atak może obejmować wiele adresów IP i kont użytkowników w celu ominięcia prób dławienia.

Widziałem w innym miejscu, że najlepiej będzie śledzić wszystkie nieudane próby logowania w całej witrynie i powiązać je z znacznikiem czasu, być może: {]}

CREATE TABLE failed_logins(
    id INT(11) UNSIGNED NOT NULL AUTO_INCREMENT PRIMARY KEY,
    username VARCHAR(16) NOT NULL,
    ip_address INT(11) UNSIGNED NOT NULL,
    attempted DATETIME NOT NULL
) engine=InnoDB charset=UTF8;

Decydować o pewnych opóźnieniach w oparciu o ogólna liczba nieudanych logowań w danym czasie. Należy oprzeć to na danych statystycznych pobranych z tabeli failed_logins, ponieważ będzie ona zmieniać się w czasie w oparciu o liczbę użytkowników i ilu z nich może przypomnieć (i wpisać) swoje hasło.

10 failed attempts = 1 second
20 failed attempts = 2 seconds
30 failed attempts = reCaptcha

Sprawdź tabelę przy każdej nieudanej próbie logowania, aby znaleźć liczbę nieudanych logowań dla danego okresu czasu, powiedzmy 15 minut:

SELECT COUNT(1) AS failed FROM failed_logins WHERE attempted > DATE_SUB(NOW(), INTERVAL 15 minute);

Jeśli liczba prób nad w danym okresie czasu przekroczysz limit, wymuszaj Dławienie lub zmuszaj wszystkich użytkowników do korzystania z captcha (tj. reCaptcha), dopóki liczba nieudanych prób w danym okresie czasu nie będzie mniejsza niż próg.

// array of throttling
$throttle = array(10 => 1, 20 => 2, 30 => 'recaptcha');

// assume query result of $sql is stored in $row
$sql = 'SELECT MAX(attempted) AS attempted FROM failed_logins';
$latest_attempt = (int) date('U', strtotime($row['attempted']));
// get the number of failed attempts
$sql = 'SELECT COUNT(1) AS failed FROM failed_logins WHERE attempted > DATE_SUB(NOW(), INTERVAL 15 minute)';
// assume the number of failed attempts was stored in $failed_attempts
krsort($throttle);
foreach ($throttle as $attempts => $delay) {
    if ($failed_attempts > $attempts) {
        // we need to throttle based on delay
        if (is_numeric($delay)) {
            $remaining_delay = time() - $latest_attempt - $delay;
            // output remaining delay
            echo 'You must wait ' . $remaining_delay . ' seconds before your next login attempt';
        } else {
            // code to display recaptcha on login form goes here
        }
        break;
    }
}

Użycie reCaptcha na określonym progu zapewniłoby, że atak z wielu frontów byłby zminimalizowany , A normalni użytkownicy witryny nie odczują znacznego opóźnienia w przypadku uzasadnionych nieudanych prób logowania. Nie mogę się powstrzymać, bo to już został rozszerzony, że CAPTCHA może być uszkodzony. Istnieją alternatywne rozwiązania, być może wariant "Nazwij to zwierzę", który mógłby działać całkiem dobrze jako substytut.

Aby podsumować schemat Jensa w pseudo diagram przejścia stanu / bazę reguł:

1. użytkownik + hasło - > wpis
2. user + !password - > denied
3. user + known_IP (user) - > front door, // never throttle
4. user + unknown_IP (user) - > catflap
5. (#denied > n) via catflaps(site) -> throttle catflaps (site) // slow the bots
6. catflap + throttle + password + captcha - > entry // humans still welcome
7. catflap + przepustnica + hasło+!captcha - > denied // a correct guess from a bot

Uwagi:

Nigdy nie zamykaj drzwi. Elbonian State police ma Twój komputer, w Twoim domu, ale nie są w stanie cię przesłuchać. Brute force to realne podejście z twojego komputera.
• Jeśli podasz " Zapomniałeś hasła?"link, a następnie Twoje konto e-mail staje się częścią powierzchni ataku.

Te obserwacje obejmują inny rodzaj ataku niż te, które próbujesz przeciwstawić.

Wygląda na to, że próbujesz bronić się przed wolno rozproszoną brutalną siłą . Nic na to nie poradzisz. Używamy PKI i nie logujemy się hasłem. To pomaga, ale jeśli twoi klienci raz na jakiś czas narażają stacje robocze, nie ma to zbyt dużego zastosowania.

Zastrzeżenie: pracuję dla firmy dwuskładnikowej, ale nie jestem tutaj, aby ją podłączyć. Oto kilka spostrzeżeń.

Pliki cookie mogą być kradzione za pomocą XSS i przeglądarek. Użytkownicy często zmieniają przeglądarki lub usuwają swoje pliki cookie.

Źródłowe adresy IP są jednocześnie dynamicznie zmienne i fałszywe.

Captcha jest przydatna, ale nie uwierzytelnia konkretnego człowieka.

Wiele metod można z powodzeniem łączyć, ale dobry smak jest na pewno w porządku.

Hasło złożoność jest dobra, wszystko oparte na hasłach zależy od haseł posiadających wystarczającą entropię. IMHO, silne hasło zapisane w bezpiecznym miejscu fizycznym jest lepsze niż słabe hasło w pamięci. Ludzie wiedzą, jak ocenić bezpieczeństwo dokumentów papierowych znacznie lepiej niż wiedzą, jak obliczyć skuteczną entropię w imieniu swojego psa, gdy są używane jako hasło do trzech różnych stron internetowych. Rozważ umożliwienie użytkownikom wydruku dużej lub małej strony pełnej jednorazowego użytku podaj kody.

Pytania bezpieczeństwa, takie jak "jaka była twoja maskotka w liceum", są w większości kolejną kiepską formą "czegoś, co wiesz", większość z nich jest łatwo zgadywalna lub wprost w domenie publicznej.

Jak zauważyłeś, ograniczanie nieudanych prób logowania to kompromis między zapobieganiem atakom brute-force a łatwością dozowania konta. Agresywne zasady blokowania mogą odzwierciedlać brak zaufania do entropii hasła.

Ja osobiście nie widzę korzyści z egzekwowania wygaśnięcie hasła na stronie w każdym razie. Atakujący dostaje Twoje hasło raz, może je zmienić i przestrzegać tej polityki tak łatwo, jak to tylko możliwe. Być może jedną z korzyści jest to, że użytkownik może zauważyć wcześniej, jeśli atakujący zmieni hasło do konta. Jeszcze lepiej byłoby, gdyby użytkownik został w jakiś sposób powiadomiony przed uzyskaniem dostępu przez atakującego. Przydatne pod tym względem są wiadomości typu "N failed attempts since last login".

Najlepsze bezpieczeństwo wynika z drugiego czynnika uwierzytelnianie, które jest poza pasmem w stosunku do pierwszego. Tak jak powiedziałeś, tokeny sprzętowe w "coś, co masz" są świetne, ale wiele (nie wszystkie) ma prawdziwe koszty administracyjne związane z ich dystrybucją. Nie znam żadnych biometrycznych rozwiązań" something you are " dobrych dla stron internetowych. Niektóre dwuskładnikowe rozwiązania współpracują z dostawcami openid, niektóre posiadają zestawy SDK PHP/Perl / Python.

Bez względu na to, jak dobry jest Twój system, zawiedzie pod wystarczająco długim atakiem. Jest tu kilka dobrych pomysłów, jak przedłużyć czas trwania hasła. (Osobiście podoba mi się pomysł wykładniczo rosnącego ograniczenia szybkości prób na użytkownika i na adres IP.), Ale bez względu na to, co zrobisz, będziesz musiał wykonać kopię zapasową niektórych zasad haseł.

Zachęcam do zastanowienia się, jak szybko można złamać hasło, i do tego, aby użytkownicy zmieniali je dwa razy częściej. Hope this pomaga.

Edit: jeśli spodziewasz się wielu leniwych atakujących, Wymaganie CAPTCHA po wielu nieudanych próbach jest dobre: podnosi nieco poprzeczkę. Jeśli martwisz się o wielu inteligentnych napastników, zatrudnij konsultanta ds. bezpieczeństwa. ;)

Moją najwyższą rekomendacją jest po prostu upewnienie się, że informujesz użytkowników o błędnych próbach logowania do ich kont-- Użytkownicy prawdopodobnie potraktują siłę swojego hasła znacznie poważniej, jeśli przedstawią im dowody na to, że ktoś naprawdę próbuje dostać się na ich konto.

Złapałem kogoś, kto włamał się na konto myspace mojego brata, ponieważ próbował dostać się na konto gmail skonfigurowałem dla niego i użyłem " Resetuj moje hasło przez funkcja e-mail... które trafiły do mojej skrzynki odbiorczej.

1. A co z wymaganiem jednorazowego hasła przed wprowadzeniem normalnego hasła? To by było oczywiste, że ktoś atakował, zanim dostał wiele okazji do odgadnięcia głównego hasła?

2. Utrzymuj globalną liczbę / wskaźnik błędów logowania - jest to wskaźnik ataku - podczas ataku bądź surowszy o niepowodzenia logowania np. szybsze zbanowanie IP.

Nie wierzę, że istnieje idealna odpowiedź, ale byłbym skłonny podejść do niej na podstawie próby zamieszania robotów, jeśli wykryje atak.

Off the top of my mind:

Przełącz na alternatywny ekran logowania. Ma wiele pustych nazw użytkownika i hasła, które naprawdę się pojawiają, ale tylko jeden z nich jest we właściwym miejscu. Nazwy pól są RANDOM - klucz sesji jest wysyłany wraz z ekranem logowania, serwer może następnie dowiedzieć się, jakie pola są jakie. Succeed or fail to then then then so you can ' t try a replay attack-if you reject the password they get a new session ID.

Każdy formularz, który jest przesyłany z danymi w niewłaściwym polu, zakłada się, że pochodzi od robota-logowanie nie powiedzie się, kropka, a IP jest dławione. Upewnij się, że losowe nazwy pól nigdy nie pasują do legalnych nazw pól, aby ktoś, kto pamięta hasła, nie wprowadzał w błąd.

Następnie, co powiesz na inny rodzaj captcha: masz serię pytań, które nie przysporzy ludziom problemów. Jednak są one Nie przypadkowe. Kiedy atak się rozpocznie, każdy otrzymuje pytanie # 1. Po godzinie pytanie #1 jest odrzucane, nigdy nie może być użyte ponownie i każdy dostaje pytanie # 2 i tak dalej.

Atakujący nie może pobrać bazy danych, aby umieścić ją w swoim robocie z powodu jednorazowego charakteru pytań. Musi wysłać nowe instrukcje do swojego botnetu w ciągu godziny, aby mieć jakąkolwiek zdolność do robienia czegokolwiek.

Ponieważ kilka osób włączyło CAPTCHA jako ludzki mechanizm awaryjny, dodaję wcześniejsze pytanie StackOverflow i wątek na temat skuteczności CAPTCHA.

Czy reCaptcha została złamana / zhakowana / OCR ' d / pokonana / złamana?

Używanie CAPTCHA nie ogranicza ulepszeń związanych z dławieniem i innymi sugestiami, ale myślę, że liczba odpowiedzi, które zawierają CAPTCHA jako alternatywę, powinna uwzględniać metody oparte na ludziach dostępne dla osób, które chcą złamać Ochrona.

Można również Dławić na podstawie siły hasła użytkownika.

Kiedy użytkownik rejestruje lub zmienia swoje hasło, oblicza się dla niego ocenę siły, powiedzmy od 1 do 10.

Coś w stylu "hasło" zdobywa 1, podczas gdy "c6eqapRepe7et * Awr@ch" może zdobyć 9 lub 10, a im wyższy wynik, tym dłużej trwa Dławienie, aby zacząć.

Pierwszą odpowiedzią, którą zwykle słyszałem, gdy zadawałem to pytanie, jest zmiana portów, ale zapomnij o tym i po prostu wyłącz IPv4. Jeśli zezwalasz tylko klientom z sieci IPv6, nie modlisz się już o proste skanowanie sieci, a atakujący będą uciekali się do wyszukiwania DNS. Nie uruchamiaj na tym samym adresie co twój Apache (AAAA)/Sendmail(MX->AAAA) / co rozdałeś wszystkim(AAAA). Upewnij się, że Twoja strefa nie może być xferd, poczekaj, aż Twoja strefa zostanie pobrana przez kogoś?

Jeśli boty znajdują ustawienia serwera nowe nazwy hostów, po prostu dołącz kilka bełkotów do nazw hostów i zmień swój adres. Pozostaw stare nazwy, a nawet Ustaw nazwy honeypot * * dla BOT net do timeout na.

** Przetestuj swoje rekordy reverse(PTR) (pod ip6.arpa.), aby sprawdzić, czy można je wykorzystać do zerowania w na /4, które mają rekordy VS /4, które nie. tzn. zazwyczaj ip6.arpa miałby ~32 "."s w adresie, ale próba z ostatnich kilku brakuje może wymknąć bloków sieciowych, które mają rekordy VS inne, które nie. jeśli weźmiesz to dalej, będzie można pominąć duże części przestrzeni adresowej.

W najgorszym przypadku użytkownicy będą musieli skonfigurować tunel IPv6, to nie jest tak, że musieliby iść tak daleko, jak VPNing do DMZ... Chociaż zastanawia się, dlaczego nie jest to pierwsza opcja.

Również Kerberos jest fajny, ale IMHO LDAP wieje (co jest technicznie nie tak z Nisplusem? Czytałem, że Sun zdecydował, że użytkownicy chcą LDAP i z tego powodu porzucili NIS+). Kerberos robi działa dobrze bez LDAP lub NIS, wystarczy zarządzać użytkownikami na podstawie hosta. Korzystanie z Kerberos daje łatwy w użyciu, jeśli nie zautomatyzowany, PKI.

Trochę za późno, ale myślałem, zakładając, że ciężki przypadek-atakujący używa wielu losowych IP, losowych nazw użytkowników i losowego hasła wybranego z listy 10.000 najpopularniejszych.

Jedną rzeczą, którą możesz zrobić, zwłaszcza jeśli system wydaje się być atakowany, ponieważ w systemie jest wiele błędnych prób haseł, a zwłaszcza jeśli hasło ma niską entropię, jest zadanie drugorzędnego pytania, na przykład Jakie są imiona twoich rodziców. Jeśli napastnik uderzy w miliony kont próbujących hasła "password1" jest duża szansa, że dostaną dużo, ale ich szanse na poprawienie nazw znacznie zmniejszą sukcesy.