Zapobieganie atakom słownikowym w aplikacji internetowej

Question

Jaki jest najlepszy sposób na zapobieganie atakom słownikowym? Wymyśliłem kilka implementacji, ale wszystkie mają pewną wadę:

1. Blokuje użytkownika po X nieudanych próbach logowania. Problem: łatwo przekształcić się w atak typu "odmowa usługi", blokując wielu użytkowników w krótkim czasie.
2. Przyrostowe wydłużenie czasu odpowiedzi na nieudaną próbę logowania na nazwę użytkownika. Problem: ataki słownikowe mogą używać tego samego hasła, ale różnych nazw użytkownika.
3. Przyrostowe wydłużenie czasu odpowiedzi na nieudaną próbę logowania z adresu IP. Problem: łatwo obejść się pod fałszywym adresem IP.
4. Przyrostowe wydłużenie czasu odpowiedzi na nieudaną próbę zalogowania w ramach sesji. Problem: łatwo obejść się, tworząc atak słownikowy, który uruchamia nową sesję przy każdej próbie.

Answer 1

Bardzo lubię system anti-brute force w Gmailu. Opiera się na "cieple", które użytkownik może zgromadzić, po przegrzaniu się użytkownika, zostaje poproszony o captcha. Możesz śledzić ciepło za pomocą bazy danych sql lub używając redis incr. Ciepło jest przypisywane do adresu IP. Nie można w 100% "podszyć" połączenia TCP przez Internet ze względu na three-way-handshake, jednak serwery proxy są obfite, a adres IP jest bardzo tani. Serwery proxy są często używane do wysyłania spamu, możesz sprawdzić numer blacklist i automatycznie poprosić ich o captcha.

Każde nieprawidłowe działanie w stosunku do systemu spowoduje aktualizację tabeli temperatur. Na przykład nieudane logowanie zgromadzi 35% ciepła. Gdy poziom ciepła jest większy lub równy 100%, użytkownik jest zmuszony rozwiązać captcha. Rozwiązanie captcha "ochłodzi" ten adres IP. Tabela temperaturowa może zawierać kolumnę znacznika czasu, która jest ustawiona na bieżący czas aktualizacji. Po upływie 24 godzin ciepło może powrócić do wartości 0.

reCaptcha jest najbezpieczniejszym captcha, którego możesz użyć.

Answer 2

Może potrzebujesz zastosować CAPTCHA w swoich formularzach internetowych.

Answer 3

Istnieje wieczna kompromis między bezpieczeństwem, dostępnością i użytecznością, co oznacza, że ​​nie ma idealnego rozwiązania.

Godnym kompromisem, w zależności od sytuacji, jest użycie opcji nr 1 z captcha. Zablokuj konto po trzech nieudanych próbach, ale zezwól na kolejne próby logowania, jeśli captcha zostanie poprawnie rozwiązany.

Answer 4

Zawsze byłem fanem twojej opcji 3 - blokowanie lub dławienie klienta na podstawie jego adresu IP. Inne opcje są bardziej kłopotliwe, niż są warte z powodów, które podałeś.

Podszywanie się pod adres IP jest możliwe, ale nie pokonuje tego środka zaradczego. Jeśli masz na myśli "podszywanie się" w sensie technicznym - wykuwanie nagłówka pakietu TCP - to nie zrobi to atakującemu zbyt dobrze, ponieważ nawet jeśli odgadną poprawne hasło, nie otrzymają odpowiedzi, która im to mówi. Oczywiście nadal mogą korzystać z serwerów proxy, ale liczba serwerów proxy jest ograniczona. Nawet jeśli atakujący ma do dyspozycji 1000 działających serwerów proxy, a Ty możesz wykonać 10 prób na IP, to jest 10 000 prób. Jeśli egzekwujesz jakąkolwiek złożoność hasła (np. Wymagając hasła alfanumerycznego), to nie wystarczy, aby zgadnąć wiele.

Samo w sobie powinno wystarczyć, aby zatrzymać większość dziecięcych skryptów.Jeśli walczysz z bardziej zdeterminowanym intruzem, prawdopodobnie musiałbyś wdrożyć jakieś monitorowanie całej witryny, które wykryłoby, że podejmowanych jest wiele prób (więc prawdopodobnie trwa atak) i "blokuje" w pewien sposób, np. . za pomocą CAPTCHA. Nie jestem fanem używania CAPTCHAs przez cały czas - są po prostu bardziej irytujące, niż są warte.

Ostatecznie to do użytkownika należy wybór bezpiecznego hasła (choć można im w tym pomóc). Jeśli wybiorą hasło "Hasło1" jako hasło, nic nie będzie w stanie powstrzymać hackera przed włamaniem się na swoje konto.

Answer 5

Polecam również za pomocą opcji 3. Chociaż nie jest tak dobry w stosunku do atakującego z dużą liczbą serwerów proxy (lub sieci typu bot), nadal uważam, że jest to najlepsza odpowiedź dla większości witryn. (Gmail ma różne zagrożenia z większości stron więc potrzebuje różne odpowiedzi.)

przykładem prawdziwy świat:
Duża gra online, które jestem zaangażowany w śledzi ilu nieudanych prób logowania pochodzić z każdego adresu IP w ciągu ostatnich 5 minut. W momencie, gdy dowolny adres IP zgromadzi 5 nieudanych prób logowania (niezależnie od liczby udanych prób), ten adres zostanie zablokowany na 45 minut.

Dlaczego to działa
Usiadłem i ustalił, że to bardzo inteligentny haker będzie mógł złamać konto w słowniku około 1 na każde 100 prób (prawdopodobnie znacznie gorzej). Tak więc, w najgorszym przypadku, atakujący dzieli 1 konto na 100 minut (na każdy adres IP). W przypadku zagrożeń związanych z tą witryną była to wystarczająca ochrona. Nasze konta naprawdę nie są warte tyle. Musisz określić (dla swojej witryny), ile potrzebujesz ochrony. Możesz przedłużyć to okno do 30 minut, jeśli chcesz, aby w razie potrzeby zajęło Ci 3 razy więcej czasu.

Ważna uwaga
Do nie reset (liczy się go do sporządzania roztworu 3 lub ciepła mapie opisano powyżej) po udanym logowaniu. Jeśli to zrobisz, atakujący po prostu spróbuje włamać się na 3 konta, a następnie zalogować się z powodzeniem na niektóre konta, które już kontrolują (ich lub już zaatakowane konto) i nigdy nie zostanie zdławiony.

Answer 6

To zależy od tego, co masz na myśli przez "zapobieganie".

Jeśli nie chcesz, aby marnowały przepustowość, przepustnica, blokada itp. Są opłacalnymi opcjami. Na górze są stoły grzewcze - musisz tworzyć i utrzymywać logikę, przechowywać i zarządzać "mapami ciepła" itp. Widziałam również systemy oparte na geolokalizacji ip, które rzucają captcha lub zmieniają jego dziennik w profilu, jeśli użytkownik próbuje zalogować się z "odległego" lub "nieznanego" adresu IP.

Jeśli chcesz po prostu znacznie zmniejszyć skuteczność ataków słownikowych, użyj soli oprócz skrótów haseł.

Answer 7

Możesz zabronić używania haseł zawierających słowa słownikowe, jeśli programujesz aplikację, w której bezpieczeństwo jest naprawdę ważne. Nie musisz dopuszczać QWERTY jako prawidłowego hasła.

Answer 8

Po pierwsze, nie pozwalaj użytkownikom wybierać typowych haseł. Dodaj "czarną listę" do swojej bazy danych i sprawdź nowe hasła przed nimi. Można wypełnić je przy użyciu jednego z wielu haseł lub słów listach, jak tutaj:

http://securityoverride.org/infusions/pro_download_panel/download.php?did=66

Po drugie, należy rozważyć tymczasowe lokautu.Jeśli masz tabelę "Użytkownik", dodaj kolumny "LastLoginAttemptedOn" i "FailedLoginAttempts". Aktualizuj te wartości za każdym razem, gdy użytkownik próbuje się zalogować. Gdy użytkownik pomyślnie się zaloguje, zresetuj FailedLoginAttempts z powrotem do 0. Gdy FailedLoginAttempts osiągnie 4 (lub cokolwiek wolisz), nie pozwól, aby użytkownik próbował zalogować się przez 5 minut (ponownie, twoje preferencje) z LastLoginAttemptedOn. Nie aktualizuj tej kolumny, dopóki w rzeczywistości nie możesz jej podjąć, aby zapobiec czterominutowej próbie zresetowania licznika czasu. Resetuj FailedLoginAttempts na 0, gdy timer zresetuje się, więc mają kilka ponownych prób.