Niedawno na konferencji OWASP AppSec 2010 w Orange County Bill Cheswick z AT&T obszernie mówił o tym problemie.

Krótko mówiąc, nie ma wystarczających badań.

W dłuższej perspektywie, oto kilka jego pomysłów na mniej bolesne blokowanie konta:

• Nie licz prób powielenia hasła (prawdopodobnie myśleli, że błędnie je wpisali)
• Podaj wskazówkę dotyczącą hasła hasło podstawowe i nie posiadaj (słabego) drugorzędnego
• Pozwól zaufanej stronie ręczyć za użytkownika, aby mógł zmienić swoje hasło.
• Zablokuj konto w coraz dłuższym czasie przyrosty
• Przypomnij użytkownikowi o zasadach dotyczących hasła.

Każda witryna internetowa zgodna ze standardami bezpieczeństwa danych PCI musi być zgodna z sekcjami

• 8.5.13 (Ogranicz powtarzające się próby dostępu, blokując identyfikator użytkownika po nie więcej niż sześciu próbach)
• 8.5.14 (Ustaw czas blokady na trzydzieści minut lub do momentu, gdy administrator zezwoli użytkownikowi ID).

Z tego powodu wiele witryn akceptujących karty kredytowe ma drakońskie zasady blokowania, mimo że ich projektanci niekoniecznie zgadzają się z tym, co zaimplementowali.

Edycja: pamiętaj, że te wymagania dotyczą tylko systemów dla „użytkowników niebędących konsumentami”, więc nie powinny mieć wpływu na witryny klientów akceptujące karty.

Z doświadczenia wiem, że popularność mechanizmów blokowania spada (przynajmniej w przypadku aplikacji internetowych). Zamiast blokować konta po serii nieudanych prób, zaczynasz prosić o dodatkowe informacje w celu pomyślnego uwierzytelnienia.

Nie zdziwiłbym się, gdyby wynikało to z zasady „trzech strajków” w baseballu, a nie z niczego technicznego.

Jednym uzasadnieniem (w każdym razie w przypadku haseł alfanumerycznych) jest

Zazwyczaj nieudana próba jest błędnym wpisaniem lub włączeniem / wyłączeniem CAPS. Więc próbujesz się zalogować i zostajesz odrzucony (1), spróbuj ponownie, ponieważ myślisz, że źle wpisałeś (2), a następnie zdajesz sobie sprawę, że klucz CAPS jest włączony, więc wchodzisz przy trzeciej próbie.

Nie nie sprawdza się w przypadku odblokowywania telefonów komórkowych z sieci, gdy zwykle jest to wprowadzany kod numeryczny.

Lepsze sugestie to stale rosnące opóźnienie między kolejnymi nieudanymi próbami logowania. Najpierw pozwalasz na natychmiastową ponowną próbę, potem 1 sekunda, 2, cztery, osiem ... Szybko czekasz minutę między próbami, co wystarczy, aby zasymulować każdy atak brutalnej siły.

Zgadzam się z OP. Jeśli myślisz o tym, przed czym chroni Cię blokada, nie ma różnicy między 3 a 20 próbami (lub 100, jeśli o to chodzi). Wszystko, co możesz osiągnąć dzięki tym blokadom, oprócz karania zapominalskich użytkowników, to zapobieganie atakowi brutalnej siły Możesz również użyć go, aby wywołać ostrzeżenie o trwającym ataku, ale nie jest to główny cel (jeśli tak było, oznacza to, że celowo robisz użytkowanie z użytkownikami, aby ułatwić sobie zadanie monitorowania. bardzo dobra praktyka).

Jeśli ktoś ma Twoją bazę danych haseł i może się do niej włamać offline, ma nieograniczoną liczbę prób. Twój limit 20 domysłów nie jest tam dobry.

Jeśli ktoś próbuje brutalnej siły w Internecie, wszystko, czego potrzebujesz, to hasło, które wytrzyma „wystarczająco długo”: wystarczająco długo, aby Twój IRT zareagował lub wystarczająco długo, aby atakujący się poddał.

Baza danych haseł Confickera jest nieco poniżej 200 haseł, IIRC, i jest wypełniona jednymi z najgłupszych haseł na świecie. Teraz załóżmy, że Twojego hasła nie ma na tej liście. Jeśli zezwolisz na 20 prób podania hasła, powiedzmy na 15 minut, bez blokowania, przedostanie się przez tę listę zajmie atakującemu więcej niż dwie godziny.

W rzeczywistości, nawet jeśli zawęzisz listę zgadywanych do haseł utworzonych na podstawie odpowiednich informacji o tym użytkowniku, takich jak kidsname02, birthday99 itp., nadal będziesz mieć co najmniej kilkadziesiąt haseł, wydłużając atak słownikowy do może godziny lub dłużej. wywołać alarmy, a nie kilka błędnych haseł w ciągu kilku minut.

Tak więc, jeśli możesz powstrzymać użytkowników przed najbardziej podstawowymi pułapkami związanymi z hasłami, możesz z radością zaakceptować wiele błędnych prób podania hasła.

Osobiście wyznaczam granicę na 15. Całkowicie arbitralna i przede wszystkim praktyczna rzecz: uważam, że każdy prawdziwy użytkownik poddał się na długo przed tym. Zwykle, jeśli jest tyle prób, jest to proces lub sesja, która wisi gdzieś ze starymi poświadczeniami. A jeśli tak nie jest, możemy porozmawiać o szukaniu ataków.

To głupia arbitralna reguła, która wiąże się z ryzykiem dziwnego rodzaju ataku DDoS. Powiedzmy, że Marv nienawidzi witryny X, a witryna internetowa X ma politykę blokowania liczby prób Y. Marv mógłby narobić poważnego piekła, gdyby skrypt automatycznie sprawdzał losowe nazwy Y razy z fałszywymi hasłami. Nawet gdyby hasło zadziałało, Marv prawdopodobnie by go nie przejął i zignorowałby je. To skutecznie zablokowałoby wielu użytkowników witryny X i spowodowałoby wiele frustracji użytkowników, a Boże pomóż im, jeśli są bankiem, do którego musisz zadzwonić, aby zresetować hasło. Jestem zaskoczony, że nikt tego nie próbował.

Wydaje mi się, że spóźniłem się na tę debatę, ale mam nadzieję, że mam tutaj coś przydatnego do dodania.

Polityka blokady konta (z liczbą kolejnych nieudanych prób, zwykle w zakresie pojedynczych cyfr dla większości organizacji) nie został wymyślony wyłącznie przeciwko zautomatyzowanym atakom siłowym.

Jest to raczej ochrona przed zgadywaniem hasła przez osoby atakujące, zwłaszcza przez osoby, które znają już część hasła. Atakujący mogli zdobyć fragmenty haseł,

• surfując po ramionach
• , odgadując wzorce stosowane przez osobę przy wybieraniu haseł. W końcu ile razy używano haseł z elementami w sekwencji, jak hasło # 01 , hasło # 02 itp.

Wadą jest oczywiście to, że przy niskiej wartości progowej z pewnością wystąpi odmowa usługi i związany z nią koszt dla biznesu. Biała księga dotycząca najlepszych praktyk w zakresie blokowania konta wydana przez firmę Microsoft zawiera zalecaną wartość 10. Wyjaśnia również, jak oszacować prawdopodobieństwo pomyślnego ataku przy użyciu parametrów z zasad blokady kont w systemie Windows:

Załóżmy na przykład, że administrator resetuje hasło, gdy konto jest zablokowane z wartością rejestru LockoutDuration równą 0. Z wartością rejestru LockoutDuration ustawioną na 0 i wartością rejestru LockoutThreshold na 20, złośliwy użytkownik ma 20 domysłów do wykorzystania w odniesieniu do tego hasła. Jeśli czas blokady wynosi 30 minut, złośliwy użytkownik co 30 minut ma 20 prób do momentu jego zmiany. Jest to bardzo znacząca różnica w całkowitej liczbie domysłów, które są dostępne dla szkodliwego użytkownika.

Dla porównania, jeśli administrator ustawi maksymalny wiek hasła na 42 dni, pierwszy złośliwy użytkownik ma tylko 20 prób z dowolnym hasłem, podczas gdy drugi szkodliwy użytkownik ma 40 320 domysłów (20 prób na zawsze blokady, pomnożone przez 48 blokad każdego dnia, pomnożone przez 42 dni przed zmianą hasła przez użytkownika). Przy domyślnych ustawieniach haseł jest około 10 ^ 12 możliwych haseł. Oznacza to, że złośliwy użytkownik ma około 0,000004 procent (%) szans na odgadnięcie hasła. Przy zoptymalizowanym schemacie zgadywania procent ten najprawdopodobniej byłby większy.

Oczywiście nie jest łatwo każdemu laikowi wybrać odpowiednią liczbę i takie decyzje powinny być ostrożne uważane. Dlatego można bezpiecznie założyć, że niektóre organizacje nie dołożyły starań, aby obliczyć skutki pieniężne ich polityki blokowania kont i związaną z tym korzyść z rozluźnienia ich zasad przy jednoczesnym zachowaniu korzyści w zakresie bezpieczeństwa, które zapewniają.

Istnieją dwa aspekty tego; pierwszą, jak wspomniałeś, jest zapobieganie atakom siłowym.

W tym celu należy wykonać naprawdę dowolną liczbę prób - 3, 5, 20, 2000 ... z odpowiednią polityką haseł (długość + złożoność + ...) zapewniającą wystarczająco dużą przestrzeń na klucze, dowolny rodzaj dławienia (X liczba prób na godzinę) zapewni, że brutalne forsowanie całej przestrzeni zajmie kilka dziesięcioleci. (Zrobić matematykę).

Nawet jeśli - a to powinno być wymaganie - blokada jest tylko tymczasowa i po krótkim czasie automatycznie się odblokowuje.

Zatem liczba prób przed zablokowaniem jest dowolna.

Istnieje jednak inny, bardziej subtelny, niematematyczny problem:

Po prostu nie ma sensu, aby pojedynczy użytkownik wielokrotnie wprowadzał błędne hasło 2000 razy z rzędu.

Oznacza to, że jeśli arbitralnie wybierzesz 2000, wiesz długo wcześniej, że NIE jest to uprawniony użytkownik. Tak więc naprawdę sprowadza się to do tego, co ma sens biznesowy, i do kompromisu związanego z analizą ryzyka.

Myślę, że historycznie rzecz biorąc, kompromis był bardziej skłonny do ryzyka - ponieważ hasła były krótsze i mniej złożone, różnica 3 lub 10 była większa. Ponadto ludzie mieli mniej haseł, więc łatwiej było je zapamiętać ... A użytkownicy byli ogólnie bardziej doświadczeni technicznie.

Obecnie trzy nie mają sensu, biorąc pod uwagę wpływ na biznes. To naprawdę kwestia tego, co ma sens dla Twojej aplikacji, jakiego typu użytkownicy, jak często się logują, itp. Zwykle zalecam sprawdzenie, ile nieudanych, legalnych prób jest prawdopodobnych, a następnie podwojenie.

( Jak wspomniał @realworldcoder, PCI arbitralnie wybrało sześć, a jeśli podlegasz PCI, nie masz tu zbytniej decyzji. W przeciwnym razie wybierz liczbę, która ma sens dla ciebie.)

Jeśli chodzi o sugestie wydłużania czasu „blokad” w celu opóźnienia kolejnych nieudanych prób, a tym samym zapobieżenia brutalnemu wymuszaniu, pamiętaj, że działa to tylko w przypadku ukierunkowanych ataków użytkowników.

Jeśli napastnikowi zależy tylko na o uzyskaniu dostępu do systemu, mogą przeprowadzić pierwszy atak wszerz (przełącz wszystkie znane / odgadnięte nazwy użytkowników przed przejściem do następnego hasła). Dodaj, że jeśli zostało to zrobione poprawnie, może pochodzić z rozproszonej sieci maszyn, łatwo jest zauważyć, że system opóźnień też nie działa.

Jak wspominali inni, poprawne monitorowanie nieudanych prób wczesne wykrywanie ataków ma kluczowe znaczenie.

Tak, 3 próby są dość arbitralne i stwarzają ryzyko DoS. Naprawdę chciałbym, żeby ludzie przestali używać systemów publicznych ... Proszę!

Inne rozwiązanie: identyfikacja dwuczynnikowa. Tokeny RSA. Gdybyśmy tylko mieli możliwość osobistego posiadania pojedynczego tokena RSA z „numerem identyfikacyjnym”. Moglibyśmy następnie zarejestrować ten „numer identyfikacyjny” w dowolnym systemie, który wymagałby wówczas bieżącej wartości z tokena wraz z hasłem do zalogowania się.

Ale to stwarza wiele innych problemów do wdrożenia i zaufanie ...

Spółki publiczne (sprzedające akcje na giełdach) podlegają przepisom ustawy Sarbanes-Oxley Act i są kontrolowane kilka razy w roku pod kątem zgodności. Krytyczne aplikacje muszą być zgodne z określonymi funkcjami bezpieczeństwa, ponieważ jednym z nich jest blokowanie kont po nieudanych próbach podania hasła.

Większość tych aplikacji polega na integracji z firmową usługą Active Directory, która ma już włączone funkcje.

Oto naprawdę fajna lektura, która omawia to, czego według mnie szukasz. Zbierali dane od studentów, którzy stosowali politykę trzech ostrzeżeń, politykę dziesięciu uderzeń i politykę nieskończonej liczby uderzeń, aby zasugerować, abyśmy podnieśli liczbę z trzech do dziesięciu (ponieważ w przybliżeniu trzykrotnie zwiększa to sukces logowania).

Wracając do subiektywnego poglądu ...

Dlaczego w większości miejsc obowiązuje zasada trzech ostrzeżeń? Z pewnością jest to tylko heurystyka, która rozwinęła się z czasem. Trzy próby to mniej więcej środek dla administratorów i użytkowników, ponieważ trzy szanse są więcej niż wystarczające.

Idea kryjąca się za hasłem jest taka, że ​​ powinno się je znać . Naprawdę nie powinieneś potrzebować więcej niż jednej próby. Rozumiem, że popełniane są błędy, ale na wojnie ... naprawdę masz tylko jedną szansę, aby udowodnić, że jesteś sojusznikiem, prawda?

Musieli wybrać losowo 3. To jest bardzo niskie. Być może mieli w przeszłości problemy z bezpieczeństwem i wybrali niski numer blokady zamiast rozwiązać lub poprawnie rozwiązać problem.

Wolę metodę blokowania użytkownika w coraz dłuższych odstępach czasu. Nie odrzuciłbym tego jednak w nazwie użytkownika, zamiast tego użyłbym adresu IP tej osoby, ponieważ ta osoba mogłaby próbować wielu nazw użytkowników. Ustawiłem czas blokady na (liczba nieprawidłowych prób logowania) ^ 2 sekundy, gdy użytkownik osiągnął 5 nieprawidłowych prób. Jeśli użytkownik nie zna swojego hasła w stosunkowo niewielkiej liczbie prób, najczęściej użyje narzędzia do odzyskiwania hasła, jeśli witryna je udostępnia. Jeśli jest to prawdziwa próba włamania, będzie to tak frustrujące dla hakera, że ​​w końcu się poddadzą. Boty będą próbować tyle razy, że prawie nigdy nie będą mogły się zalogować ... na przykład, jeśli spróbują 1000 haseł (co i tak zajęłoby dużo czasu), musiałyby poczekać 11 i pół dnia, zanim będą mogły wypróbuj 1001 hasło. Możesz łatwo zwiększyć zdolność odstraszania, zwiększając mnożnik do ^ 3. Wszystko powyżej może być trochę za wysokie dla prawidłowych użytkowników.

Niedawno wdrożyłem schemat bezpieczeństwa logowania, który był zgodny z następującymi podstawowymi zasadami:

1. Pierwsza nieudana próba daje natychmiastową informację zwrotną. Prawdopodobnie dotknęli go grubymi palcami.
2. Druga do piątej nieudana próba powodowała opóźnienie odpowiedzi o jedną sekundę na nieudaną próbę. np. 2 sekundy, 3 sekundy, 4 sekundy ...
3. Jeśli piąta próba się nie powiodła, sesja została zakończona i pojawił się komunikat wskazujący, że będą musieli zamknąć przeglądarkę i spróbować ponownie.

Dla mnie to było więcej niż wystarczające, aby zapobiec atakom brutalnej siły; byłoby co najwyżej niedogodnością dla użytkowników końcowych i nie powodowałoby dodatkowej pracy w zakresie pomocy technicznej.