https://archive.mroczna-zaloga.org/ Paweł Goleń, blog - Zrzędzenie starego zgreda pl Serendipity - http://www.s9y.org/ Sat, 15 Mar 2025 22:14:08 GMT https://archive.mroczna-zaloga.org/templates/bulletproof/img/s9y_banner_small.png https://archive.mroczna-zaloga.org/ 100 21 https://archive.mroczna-zaloga.org/archives/635-o-implementowaniu-hasel.html#c1181 https://archive.mroczna-zaloga.org/archives/635-o-implementowaniu-hasel.html#comments https://archive.mroczna-zaloga.org/wfwcomment.php?cid=635 nospam@example.com (wampir) Sam wiesz, że skuteczne "otagowanie" intruza jest, delikatnie mówiąc, trudne. Tworzenie mechanizmów, których "wartość dodana" jest marginalna trochę mija się z celem, a zwiększa prawdopodobieństwo, że mechanizmy te zostaną przeciwko systemowi wykorzystane (choćby do DoS). Poza tym nawet przy skanowaniu "wszerz" w przypadku zastosowania mechanizmu opóźnień, sprawdzenie każdego użytkownika przy pierwszym przebiegu zajmuje 1 sekundę, później 2 sekundy, później 4 sekundy, później (...). Pokusiłbym się ewentualnie o monitorowanie/wykrywanie anomalii (w tym wypadku ilość prób logowania do systemu w jednostce czasu) i reakcję na wystąpienie anomalii tego typu - np. wymaganie CAPTCHA przy każdej próbie uwierzytelnienia. Mon, 29 Jun 2009 17:39:43 +0200 https://archive.mroczna-zaloga.org/archives/635-guid.html#c1181 https://archive.mroczna-zaloga.org/archives/635-o-implementowaniu-hasel.html#c1180 https://archive.mroczna-zaloga.org/archives/635-o-implementowaniu-hasel.html#comments https://archive.mroczna-zaloga.org/wfwcomment.php?cid=635 nospam@example.com (Marcin Gryszkalis) A zabezpieczacie się w takim razie przed skanowaniem "wszerz", tzn. bierzemy typowe popularne hasło i lecimy po standardowych userach (adam, adam1, adam2...)? Mon, 29 Jun 2009 15:22:08 +0200 https://archive.mroczna-zaloga.org/archives/635-guid.html#c1180 https://archive.mroczna-zaloga.org/archives/635-o-implementowaniu-hasel.html#c1179 https://archive.mroczna-zaloga.org/archives/635-o-implementowaniu-hasel.html#comments https://archive.mroczna-zaloga.org/wfwcomment.php?cid=635 nospam@example.com (wampir) Tak, aplikacja co do zasady nie powinna ujawniać informacji o prawidłowych loginach użytkowników, choć czasami może się to mijać z celem. Przykład: wss.pl - komunikat dla istniejącego jak i nieistniejącego użytkownika jest ten sam (nie sprawdzałem dogłębnie), jednak enumeracji użytkowników bez problemów można dokonać zaglądając na forum z założenia dostępne dla wszystkich, albo poprzez również dostępny dla wszystkich formularz rejestracji (nie można założyć konta o loginie, który jest już zajęty). Jeśli chodzi natomiast o "odsiewanie DoS", to podstawowym problemem może być zidentyfikowanie tego, co jest częścią ataku DoS, a co normalnym działaniem użytkownika. W szczególności może zdarzyć się tak, że odpowiednio "zirytowany" mechanizm "odsiewania DoS" może sam swą nadgorliwością zablokować dostęp prawdziwym, potulnym użytkownikom... Mon, 29 Jun 2009 14:03:24 +0200 https://archive.mroczna-zaloga.org/archives/635-guid.html#c1179 https://archive.mroczna-zaloga.org/archives/635-o-implementowaniu-hasel.html#c1177 https://archive.mroczna-zaloga.org/archives/635-o-implementowaniu-hasel.html#comments https://archive.mroczna-zaloga.org/wfwcomment.php?cid=635 nospam@example.com (Marti) Bardzo istotna uwaga - non-existing user powinien być traktowany dokładnie tak samo jak istniejący, co prawda w przypadku ataku DoS liczenie tego wszystkiego powoduje overhead dla aplikacji. Stąd jestem również zwolennikiem revProxy które pośredniczy w komunikacji aplikacja user i może zająć się procesem wycinania DoSu i niedopuszczania go do samego serwera aplikacji. Co wg mnie jest bardziej opłacalne z punktu widzenia nawet dodatkowego skomplikowania infrastruktury (gdyż np. taki revProxy również musi być poddany procesowi High Availability). Mon, 29 Jun 2009 09:57:32 +0200 https://archive.mroczna-zaloga.org/archives/635-guid.html#c1177 https://archive.mroczna-zaloga.org/archives/635-o-implementowaniu-hasel.html#c1171 https://archive.mroczna-zaloga.org/archives/635-o-implementowaniu-hasel.html#comments https://archive.mroczna-zaloga.org/wfwcomment.php?cid=635 nospam@example.com (wampir) Per-user. Po stronie aplikacji należy utrzymywać informację dla każdego użytkownika o ilości nieudanych prób logowania (licznik resetowany po udanym uwierzytelnieniu) i do tego prosty sleep. W zasadzie należy utrzymywać też takie liczniki dla nieistniejących użytkowników, tak, by opóźnienie i wymaganie CAPTCHA było realizowane również dla nieistniejących użytkowników, tak, by nie wyciekała informacja o (nie)istniejących kontach. Sun, 28 Jun 2009 09:31:34 +0200 https://archive.mroczna-zaloga.org/archives/635-guid.html#c1171 https://archive.mroczna-zaloga.org/archives/635-o-implementowaniu-hasel.html#c1170 https://archive.mroczna-zaloga.org/archives/635-o-implementowaniu-hasel.html#comments https://archive.mroczna-zaloga.org/wfwcomment.php?cid=635 nospam@example.com (Marcin Gryszkalis) Co do opóźnienia - w jaki sposób chcesz to zrealizować w przypadku aplikacji internetowej, biorąc pod uwagę, że - atakujący może mieć w nosie ciasteczka, - może randomizować User-Agent i wszystkie inne nagłówki - a ze względu na NAT-y nie bardzo możemy pozwolić sobię na robienie tego per-IP (biorąc pod uwagę popularne aplikacje internetowe to z jednego adresu źródłowego mamy całkiem sporo logowań na minutę). Sat, 27 Jun 2009 23:27:30 +0200 https://archive.mroczna-zaloga.org/archives/635-guid.html#c1170