eGospodarka.pl
eGospodarka.pl poleca

eGospodarka.plFinanseGrupypl.biznes.bankibezpieczeństwo a' la Inteligo - tp mit :-(Re: bezpieczeństwo a' la Inteligo - tp mit :-(
  • Data: 2002-04-09 10:12:25
    Temat: Re: bezpieczeństwo a' la Inteligo - tp mit :-(
    Od: "Rafal Smigielski" <r...@b...pl> szukaj wiadomości tego autora
    [ pokaż wszystkie nagłówki ]


    Użytkownik "Adam_mb" <m...@i...pl> napisał w wiadomości
    news:Xns91EAB3F3361CFx2e5@150.254.173.2...
    > >całkowicie dyskwalifikuje poziom bezpieczeństwa. Jak banki nie są w
    stanie
    > >tego zapewnić, to niech chociaż stosują bardziej skomplikowane hasła
    > >jednorazowe (powiedzmy małe, duże litery i cyfry, długość 12-14 znaków) i
    > >wtedy zapisują jedynie skróty - to trochę urealni te zabezpieczenia.
    >
    > hmm, a czy crypt(crypt(crypt("moje_tajne_haslo"))) zwieksza czas
    odtwarzania
    > hasła?
    >
    > Bo zakodowanie takiego hasła jest nadal proste (krótkie), a może rosnie
    czas,
    > nazwijmy to eufemistycznie, "dekompresji"? I już nie 5h, tylko 7 tygodni
    albo
    > 13 miesiecy na tej samej maszynce...
    >
    > Bezpieczeństwo kodowanych haseł polega na tym, że jesli od np. awarii
    systemu
    > (włamania itd.) do wykrycia tego faktu nie upłynie zbyt długi czas, to
    fakt
    > potrzeby użycia odpowiedniego czasu na crackowanie daje pewne
    bezpieczeństwo
    > systemowi i jego administatorom - na wykrycie luki, zmiane haseł czy
    > zablokowanie danego kanału...
    >
    > Lepiej mieć 5 godzin niż 5 sekund, lepiej 7 tygodni niż 5h.
    >

    Zgadzam się całkowicie - jednak należałoby sytuację trochę odwrócić:
    najważniejszą sprawą wydaje mi się minimalizowanie czasu, jaki jest
    udostępniany na próbę złamania haseł i to zarówno dla ataków zewnętrznych
    jak i wewnętrznych.
    Użycie tokenów kryptograficznych wykorzystujących funkcje czasowe powoduje,
    że w efekcie do systemu autoryzacyjnego banku dociera od użytkownika efekt
    funkcji crypt ("hasło_autoryzacyjne", crypt("tajny_kod_tokena"),
    "czas_systemowy"). Oczywiście w duzym uproszczeniu. System autoryzacyjny po
    stronie banku nie przechowuje lecz na bieżąco wylicza wartość tej funkcji
    dla wywołania autoryzacyjnego opierając się na znajomości poszczególnych
    argumentów i funkcji crypt. Wyznacza więc wartość crypt
    ("hasło_autoryzacyjne", crypt("tajny_kod_tokena"), "czas_systemowy") i
    porównuje wartość wyzaczoną z przekazaną przez użytkownika.
    System autoryzacyjny przechowuje jedynie skrót "tajnego_kodu_tokenu", reszta
    informacji jest pobierana lub generowana przez system ("czas_systemowy" -
    pobierany, "hasło_autoryzacyjne" - generowane, często losowo, lecz zależy to
    od potrzeb i zastosowań).

    I teraz najistotniejsze - efekt działania funkcji crypt jest wiarygodny
    tylko w wyznaczonym przedziale czasu (rzędu kilkunastu - kilkudziesięciu
    sekund).

    Próby typu "brute force" z zewnątrz są skazane na niepowodzenie gdyż jest na
    to zbyt mało czasu a ilość prób jest ograniczona (z reguły do trzech). Próby
    podszycia się pod użytkownika przez pracownika banku też graniczą z
    niemożliwością z tego samego względu oraz ze względu na brak możliwości
    pozyskania informacji o "tajnym_kodzie_tokenu" i nieprzewidywalności
    elementu generowanego ("hasło_autoryzacyjne").

    Zaznaczam, że "hasło_autoryzacyjne" jest hasłem generowanym przez system
    jako wywołanie dla danej sesji autoryzacyjnej i nie ma nic wspólnego z
    typową autoryzacją user/password, która z reguły jest równiez wykorzystywana
    jako wzmocnienie całego procesu autoryzacji - stanowi po prostu pierwszy
    krok.

    Pozdrawiam
    RS


Podziel się

Poleć ten post znajomemu poleć

Wydrukuj ten post drukuj


Następne wpisy z tego wątku

Najnowsze wątki z tej grupy


Najnowsze wątki

Szukaj w grupach

Eksperci egospodarka.pl

1 1 1