Użytkownik "xbartx" <b...@h...net> napisał w wiadomości
news:i3ufqg$9j7$1@news.net.icm.edu.pl...
> Dnia Wed, 11 Aug 2010 13:18:21 +0200, Piotr Gałka napisał(a):
>
>> To jest jasne cały czas.
>> Na moje wyczucie system akceptujący do 10 000 logowań na minutę będzie
>
> Widzisz, mam wrażenie, że rozpatrujesz to dalej, jako jednostkowy atak,
> który ma się odbyć w jak najkrótszym czasie ale nie o to chodzi.
Ja rozpatruję atak wieczysty, ale wymagający powtórzenia całej sekwencji co
minutę, aby utrzymać blokady aktywne. Jednocześnie zakładam, że system nie
pozwoli odkryć prawdziwych loginów więc blokowane będzie tyle ile się da,
ale bez gwarancji, że są istniejące.
Ja nie zacząłem od opisu ataku tylko od mojej propozycji (wymyślonej w parę
minut, więc prawdopodobnie dalekiej od doskonałości) jak takie blokowanie
powinno wyglądać od strony systemu (że po minucie się odblokowuje),
argumentując, że takie ograniczenie pasma jest wystarczające aby
uniemożliwić odkrycie prawdziwych loginów.

> Próba nieudanych logowań może trwać powiedzmy przez dwa tygodnie (albo i
> dłużej) czyli im dłużej tym większe prawdopodobieństwo, że logowanie
> będzie celne przy strzelaniu losowo. Jeżeli bank umożliwiałby
> potwierdzenie, który login jest używany wtedy można tworzyć bazę takich
> loginów.

No właśnie ja się trzymam mojej wersji z założeniem, że tego nie da się
potwierdzić. Nie że w obecnych systemach się nie da, tylko, że takie było
moje założenie w pierwszej mojej wypowiedzi.

Nie wiem, czy tak to jest robione, ale w pierwszym podejściu uważam, że z
komputera użytkownika do systemu powinny być przesyłane:
- login
- zestaw: (hasło+tzw. sól) wydłużony kryptograficznie o minimum 20 bitów (na
PC zajmie około 1s). Dopiero długi (np. 256 bitów) wynik jest przesyłany.
Sól to dość długa (np. 128 bitów) jawna! stała dla danego użytkownika, ale
dla każdego inna. Powoduje to, że atakujący sprawdzając wszystkie domniemane
hasła nie może wykorzystać efektu skali. Nie może raz wyliczyć wydłużenia
hasła i sprawdzić je dla miliona loginów tylko musi dla jednego sprawdzanego
hasła obliczać to wydłużenie milion razy. A próbowanie wysyłania losowych
wartości wyników (tych 256 bitów) mija się z celem ze względu na liczbę
kombinacji.

> Z technicznego punktu widzenie obrona banku przed takim, jak to
> nazwałem "atakiem", jest w zasadzie mocno ograniczona, bo ciężko mi sobie
> wyobrazić aby bank tworzył listę IP, które mają/nie mają dostęp do
> logowania a na 3 próby musi zezwolić aby móc według procedury zablokować
> konto.
>
Moja teza (od początku) jest taka, że blokowanie na minutę (XX minut) jest
wystarczające dla uniemożliwienia znalezienia atakującemu prawdziwego hasła
(nie chodzi o to, że ten atak ma to na celu, tylko o spełnienie celu dla
którego stosowane jest blokowanie po 3 nieudanych próbach), a jednocześnie
zabezpiecza bank przed lawiną telefonów o zablokowanym loginie. I druga jest
taka, że dodatkowo bank nie powinien pozwolić odkryć używanych loginów. I
trzecia że tylko jeden na 1000 losowych loginów powinien trafiać w używany
login.
P.G.