Blokowanie kont to po pierwsze zły pomysł. Może się wydawać, że zwiększasz bezpieczeństwo swojej organizacji, powstrzymując „złych ludzi”, którzy „odgadują” hasła przy użyciu brutalnej siły ataki, ale co tak naprawdę rozwiązałeś? Nawet przy takiej polityce i doskonałej bazie użytkowników, która nigdy nie popełnia błędów w zabezpieczeniach, osoba atakująca może przeprowadzić atak typu „odmowa usługi” na Twoją organizację, wielokrotnie używając hasła „aaa” do blokowania kont użytkowników krytycznych. Zastanów się, co się stanie, jeśli osoba atakująca otrzyma kopię listy nazw użytkowników dla całego działu IT: nagle samo IT - organizacja, która w przeciwnym razie mogłaby odblokować innych użytkowników - zostaje całkowicie zamknięta.

Zawsze rozważ model zagrożenia przed wdrożeniem polityki. „Zły facet” zdeterminowany, by skrzywdzić Twoją organizację, znajdzie alternatywne wektory ataku. Twoja polityka lokautu nie zrazi nawet aktora państwowego (takiego jak Rosja, Chiny czy NSA); zdeterminowany haker po prostu znajdzie inne sposoby obejścia tego problemu (np. socjotechnika); i tylko zaszkodzi legalnym użytkownikom twojej usługi, bez względu na to, jak nisko lub wysoko ustawisz licznik blokady.

Morał z tej historii: Nie blokuj kont. Zamiast tego , zrób to, co Apple robi z iPhonem: każda próba logowania podwaja opóźnienie logowania, tak że po kilkunastu nieudanych próbach musisz odczekać godzinę pomiędzy kolejnymi próbami. To wystarczająco długo, aby uniemożliwić „złym facetom” wykonywanie ataków siłowych, ale wciąż wystarczająco krótkie, aby legalny użytkownik mógł spędzić tę godzinę, zastanawiając się, jakie jest jego hasło i wpisując je poprawnie po obiedzie - lub kontaktując się z IT i przepraszająco prosząc o pomoc . (Podobnie, zasady „zalewania” można często wdrożyć na poziomie adresu IP w zaporze, a nie tylko na poziomie konta użytkownika w oprogramowaniu, jeśli obawiasz się, że dedykowany napastnik próbuje brutalnie wymusić wiele różnych kont .)

A jeśli nie blokujesz kont, nie musisz mieć licznika - ani wyświetlać go.

[ zobacz także: tę doskonałą odpowiedź na podobne pytanie ]

To zależy od mechanizmu blokady. Jeśli nieprawidłowe dane logowania zostaną zresetowane po pewnym czasie ORAZ zablokowane konto nie zostanie odblokowane, pokazanie licznika może pomóc atakującemu w niezablokowaniu konta. Jednak wykwalifikowany napastnik określi z góry zasady blokowania i weźmie to pod uwagę podczas odgadywania hasła. Więc wpływ jest ograniczony.

Również poleganie na tym w celu ochrony mechanizmu logowania nie ma sensu. Powinieneś mieć przyzwoitą politykę haseł i pasującą politykę blokowania. Jeśli zasada dotycząca haseł jest silna, osoba atakująca będzie musiała odgadnąć wiele razy, zanim będzie dobrze. Jeśli zablokujesz konto po 20 próbach, masz niewielkie szanse na włamanie.

Musisz zadać sobie pytanie: jaka jest korzyść z pokazania tych informacji prawdziwemu użytkownikowi? Często ten problem z blokadą występuje, ponieważ liczba prób jest ustawiona zbyt mała. 3 lub 5 to typowe wybory. NIST (obecnie niedostępny z powodu zamknięcia rządu, więc nie ma jeszcze bezpośredniego odniesienia) sugeruje mniej niż 100 prób.

NIST ma rację: pomyśl o haśle, którego żaden napastnik nie odgadnie w 3 próby, ale które zgadną w 100 próbach. Wszyscy napastnicy używają różnych słowników i podejść. Jeśli hasło nie wytrzymuje 100 prób, można je złamać, wykonując mniejszą liczbę prób - chociaż jest to mniej prawdopodobne. Dlatego dobra polityka haseł jest koniecznością.

Dodam odniesienia NIST, gdy witryna zostanie ponownie uruchomiona. Troy hunt ma kilka dobrych postów na blogu, które podsumowują hasła i mechanizmy logowania. Jest również fanem wytycznych NIST.

W zasadzie nie, nie powinno to stanowić zagrożenia dla bezpieczeństwa. Gdyby tak było, polegałbyś na bezpieczeństwie poprzez zaciemnienie (ukryte informacje).

Ukrywanie liczby byłoby w najlepszym przypadku niewielką niedogodnością dla przeciwnika.

W przeciwieństwie do tego, ukrycie liczby może być znaczną niedogodnością dla uprawnionych użytkowników. Nierzadko zdarza się, że czasami wpisuję nieprawidłowe hasło, a następnie wpisuję je jeszcze kilka razy, zakładając, że popełniłem literówkę. Jeśli wiem, że zostanie mi zablokowana kolejna niepoprawna próba, poszukam hasła i skopiuję / wkleję lub wpiszę je ostrożnie. Jeśli jednak nieświadomie zablokuję sobie dostęp do swojego konta, teraz muszę wykonać wiele dodatkowych problemów, aby je odblokować.

Aby spojrzeć na to z innej perspektywy: nie ma to znaczenia dla wprawnego napastnika .

W jaki sposób konta internetowe są dziś atakowane zazwyczaj ¹ ? Istnieją dwie powszechnie stosowane techniki.

Bazy danych ze skrótami haseł (lub hasłami w postaci zwykłego tekstu) są kradzione i łamane offline przez atakujących. Po pomyślnym złamaniu hasha poprawne hasło jest podawane do mechanizmu logowania przy pierwszej próbie, więc ta kontrola jest nieskuteczna.

Może to być baza danych danej usługi lub baza danych innej usługi. Niestety, ludzie mają tendencję do ponownego wykorzystywania swoich haseł w kilku usługach, więc istnieje duże prawdopodobieństwo, że po dopasowaniu hasła do adresu e-mail można go użyć w innej witrynie. Atakujący może mieć do wyboru dwa lub trzy hasła, ale prawdopodobnie nie 20. Ponownie, ta kontrola jest nieskuteczna.

Jaki poziom bezpieczeństwa zapewnia ta kontrola? Poziom niezbędny do ochrony przed niedoświadczonymi dzieciakami od skryptów, złośliwymi byłymi partnerami i wścibskimi rodzicami, którzy chcą spojrzeć na twoje konto osobiste i wypróbować pięć losowych haseł. Nie więcej, ale nie mniej.

^{1 Są oczywiście inne bardziej „zaawansowane” techniki, takie jak keylogging, (spear) -phishing, MitM itp., Które również są nie ograniczane przez tę kontrolę.}

Możliwe są tylko dwa scenariusze, ale raczej pokazanie, że polityka czasu blokady konta jest bardziej związana z czasem blokady.

Np.

• raz można skonfigurować hydrę lub inne narzędzie do brutalnego wymuszenia logowania i poczekaj po 3 próbach. jeśli nie masz wystarczającego czasu na blokowanie, może to spowodować włamanie na konto.

• jeśli masz około 30 minut na blokowanie, możemy skonfigurować narzędzie do brutalnej siły i poczekaj, a po trzech próbach złamanie hasła zajmie lata.

Aby to zakończyć, nie ma ryzyka związanego z wyświetleniem próby zablokowania konta.

Generalnie skłaniam się ku temu, że im mniej informacji przekazujesz napastnikowi, tym lepiej. Jak wspomniał @ security-beast, narzędzie można skonfigurować tak, aby czekało przez odpowiednią ilość czasu. Przekazywanie im informacji dotyczących tej konfiguracji niekoniecznie jest idealne.

Jednak musisz to zrównoważyć z potrzebami użytkowników. Czy uważasz, że administratorzy systemu spędzają nadmierną ilość czasu na odblokowywaniu kont, ponieważ użytkownicy ciągle je blokują? W takim przypadku Twoja analiza może wskazywać, że możesz odnieść większe korzyści z wyświetlania liczby ponownych prób użytkownikom, aby wiedzieli, kiedy muszą czekać przed zablokowaniem swoich kont. W innych przypadkach będzie odwrotnie, ale tak czy inaczej odpowiedź powinna być wynikiem obiektywnej analizy kompromisów dla konkretnego systemu.

Mam nadzieję, że to pomoże.

Ryzyko bezpieczeństwa jest subiektywne, będzie zależało od tego, co próbujesz chronić cel kontroli bezpieczeństwa i jakiejkolwiek innej kontroli bezpieczeństwa na miejscu, która łagodzi lub kompensuje ryzyko.

Na podstawie różnych firm / biznes będzie inaczej akceptował to samo ryzyko.

Jeśli w ogólny sposób podanie liczby prób, które nadal masz, może nie wiązać się z ryzykiem (np. kod PIN na karcie inteligentnej do wykonywania połączeń telefonicznych) W innych sytuacjach może to stanowić ryzyko (np. brute force dostęp do telefonu komórkowego), gdzie można zatrzymać się przed ostatnią próbą i odczekać chwilę, aby użytkownik zresetował licznik z ważnym dostępem ...

Należy sprawdzić cel kontroli bezpieczeństwa, co próbujesz chronić i jakie środki bezpieczeństwa masz na miejscu, które kompensują lub przynajmniej monitorują nietypowe sytuacje.

Na podstawie tego wszystkiego możesz zdecydować, czy jest to akceptowalne ryzyko, czy nie.

W pewnym momencie byłem w firmie, w której kilku facetów przetestowało ich bezpieczeństwo. Jedną z rzeczy, które odkryli ci faceci, jest to, że nie było blokady konta, gdy było zbyt wiele nieprawidłowych haseł. Jednak ku radości CISO nie byli w stanie udowodnić, że rzeczywiście mogli dostać się do środka poprzez brutalne wymuszenie hasła. Powodem tego było to, że blokada konta była cicha i trwała około 15 minut.

Zadaj sobie pytanie, co zyskujesz wyświetlając taki komunikat, a co tracisz w ten sposób na bezpieczeństwie. Nie ma sensu powiadamianie o zablokowaniu konta z powodu zbyt wielu nieprawidłowych prób logowania. Jeśli przekażesz taką wiadomość, po prostu pomożesz napastnikowi w ustaleniu, kiedy marnuje swój czas brutalną siłą. Jeśli tego nie zrobisz, rzadziej się zorientują, ale może to prowadzić do większej liczby telefonów / e-maili do twojego helpdesku, co może być kosztowne. FAQ lub strona pomocy może to zmniejszyć.

Również wdrożenie odliczania prawdopodobnie oznaczać będzie więcej kodu, a więcej kodu oznacza więcej błędów. To nie jest coś, czego oczekujesz od mechanizmu bezpieczeństwa. Dodając do tego, że źle ją zaimplementujesz, może to pozwolić atakującym na wyliczenie nazw użytkowników, co jest podwójnie problematyczne, jeśli są to adresy e-mail. Do diabła, jeśli zaimplementujesz to za pomocą niepodpisanego pliku cookie, może to w rzeczywistości dać atakującemu możliwość zapobieżenia blokadzie. .