> skoro moze drukowac je powtornie to znaczy ze:
> - albo pierwsze haslo z listy nie jest "calkiem przypadkowe"
> i lista zaczyna sie od jakiejs pamietanej jednej liczby
> a wtedy caly proces mozna w kazdej chwili powtorzyc
> - albo drukuje i nie zapomina - pamieta cala liste

Jakby nie bylo - sprawa jest podejrzana.

> Pamietam ze generator liczb pseudolosowych wystartowany
> pare razy z tej samej liczby dawal taki sam ciag odpowiedzi.
> Oczywiście taki generator ktory zadnych innych parametrow nie pobiera

Powiem wiecej - komputery nie sa dobrymi generatorami liczb losowych
(dlatego nazwa pseudolosowych). Osobiscie twierdze, ze kazda "losowa"
(pseudolosowa) liczbe wygenerowana przez komputer mozna wygenerowac ponownie.

Maurycy

--
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/

do góry

> 1000000) możliwości i mogę wszystkie sprawdzić. Twoje hasło do linuxa może
> składać się z kombinacji małych i dużych literek, cyfr i znaków specjalnych
> i może mieć dowolną długość. Tak na oko około 10^40 możliwości, czyli

tak nie na oko, to jest (liczba mozliwych znakow)^(dlugosc hasla),
alfabet angielski (male i duze), cyfry i znaki to jakies 97^n,
gdzie n - dlugosc hasla,
teraz tak na oko to jest 100^n = 10^(2n), czyli wykladnik razy dwa

do góry

On Fri, Apr 05, 2002 at 08:16:16PM +0200, Darek R. wrote:

> > pasat:$1$7PAfYb85$21A1xWPE0SUzZ12I2mnC61:11782:0:999
99:7:::
> >
> > z podobnego linuxa ;-)
>
> O ile mój Johny się nie pomylił to hasło brzmi 1234
> Zgadłem?

Brawo!

Ale w systemach bankowych wystarczy ze md5 bedzie liczone od jakis
fajnych rzeczy (a nie tylko od klucza) i juz nasz riper wysiada.

--

--w
--
Archiwum grupy: http://niusy.onet.pl/pl.biznes.banki

do góry

Wojtek Piecek wrote:
> Ale w systemach bankowych wystarczy ze md5 bedzie liczone od jakis
> fajnych rzeczy (a nie tylko od klucza) i juz nasz riper wysiada.

Zauważ, że potem prawdziwość hasła musi być werfikowalna, więc albo te
"fajne rzeczy" też są gdzieś zapisane (i jeśli mam dostęp do bazy ze
"skrótami haseł" to do bazy z "fajnymi rzeczami" pewnie też), albo są jakoś
generowane - czyli wystarczy że poznam ten tajny algorytm generujący "fajne
rzeczy". Czyli tak jak pisałem - jeśli informatyk (czy ktokolwiek inny) ma
dostęp do bazy czy to z gotowymi "hasłami", czy ze "skrótami" (i wie jak są
tworzone) to taki poziom zabezpieczeń nadaje się do wyrzucenia. Jedyna
informacja jaką powinno się dać wydrzeć z systemu to to czy dane hasło
wpisaliśmy poprawnie (i blokada po trzecim błędnym wpisaniu) (no i dodatkowo
zabezpieczenie przed sprawdzaniem hasła na wielu kontach - wybieramy jakieś
hasło i lecimy przez wszystkie konta - przy takich hasłach (6 cyferek)
trafimy dość szybko). Takie coś jak możliwość stworzenia duplikatu listy
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.

--
Pozdrowienia
Darek Rzońca
http://drzonca.republika.pl - Zagadki lateralne, dowcipy, warcaby,
kostka Rubika a nawet sposób na nieśmiertelność!

do góry

>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.

--
<xml-sig>
<header> Adam
</xml-sig>

do góry

Adam_mb wrote:
> hmm, a czy crypt(crypt(crypt("moje_tajne_haslo"))) zwieksza czas
> odtwarzania hasła?

Pewnie trochę zwiększa, ale w sumie nie aż tak znacznie ... Generalnie -
jeśli algorytm kodowania jest 2 razy bardziej skomplikowany obliczeniowo to
czas na złamanie też będzie 2 razy dłuższy (zakładając, że nie ma jakiejś
dziury, która umożliwia złamanie inaczej niż brute-force). Za to np.
wydłużenie hasła o jeden znak (zakładając, że hasło jest złożone z dowolnych
znaków - litery małe, duże, cyfry, znaki specjalne, czyli np. tak jak hasło
do logowania do linuxa) zwiększy ten czas około 100 razy (dokładnie - tyle
razy ile jest możliwych znaków). Wydłużenie o dwa znaki zwiększy ten czas
10000 razy ...

--
Pozdrowienia
Darek Rzońca
http://drzonca.republika.pl - Zagadki lateralne, dowcipy, warcaby,
kostka Rubika a nawet sposób na nieśmiertelność!

do góry

Użytkownik "Darek R." <d...@...pl> napisał w wiadomości
news:a8tbds$rba$1@news.tpi.pl...
> Adam_mb wrote:
> > hmm, a czy crypt(crypt(crypt("moje_tajne_haslo"))) zwieksza czas
> > odtwarzania hasła?
>
> Pewnie trochę zwiększa, ale w sumie nie aż tak znacznie ...
W większości przypadków nie będzie miało żadnego wpływu. Np. DES
DES(k1,DES(k2,t)) = DES (k3,t) gdzie k1,k2,k3 to różne klucze, a t to tekst.
Wiele algorytmów jest łączna (nie myliś z przemienna). Więc stosowanie
wielekrotnego kodowania mija się po prostu z celem.
>Generalnie -
> jeśli algorytm kodowania jest 2 razy bardziej skomplikowany obliczeniowo
to
> czas na złamanie też będzie 2 razy dłuższy (zakładając, że nie ma jakiejś
> dziury, która umożliwia złamanie inaczej niż brute-force). Za to np.
> wydłużenie hasła o jeden znak (zakładając, że hasło jest złożone z
dowolnych
> znaków - litery małe, duże, cyfry, znaki specjalne, czyli np. tak jak
hasło
> do logowania do linuxa) zwiększy ten czas około 100 razy (dokładnie - tyle
> razy ile jest możliwych znaków). Wydłużenie o dwa znaki zwiększy ten czas
> 10000 razy ...
To jest prawda - dla większości algorytmów kodowania hasła.

do góry

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

do góry

On Tue, 9 Apr 2002 11:41:19 +0200, Stefan <s...@i...pl> wrote:
>> > hmm, a czy crypt(crypt(crypt("moje_tajne_haslo"))) zwieksza czas
>> > odtwarzania hasła?
>>
>> Pewnie trochę zwiększa, ale w sumie nie aż tak znacznie ...
> W większości przypadków nie będzie miało żadnego wpływu. Np. DES
> DES(k1,DES(k2,t)) = DES (k3,t) gdzie k1,k2,k3 to różne klucze, a t to tekst.
> Wiele algorytmów jest łączna (nie myliś z przemienna). Więc stosowanie
> wielekrotnego kodowania mija się po prostu z celem.

DES nie jest łączny.

--
Pozdrowienia.
*-[ Paweł Grajewski ]----------[ g...@w...pl ]--*

do góry

"Maurycy" <m...@N...poczta.gazeta.pl> writes:

> Powiem wiecej - komputery nie sa dobrymi generatorami liczb losowych
> (dlatego nazwa pseudolosowych). Osobiscie twierdze, ze kazda "losowa"
> (pseudolosowa) liczbe wygenerowana przez komputer mozna wygenerowac ponownie.

Swiadomie? Bzdura. Tak bylo, gdy generatory nie uzywaly zadnych
zewnetrznych (wzgledem siebie) zmiennych. Od czasu, gdy uzywaja
"random pool", zasilanego calkowicie niedeterministycznymi
zdazeniami (np. najmniej znaczacymi bitami z szumu rezystora),
nie da sie tego nijak przewidziec.
--
Krzysztof Halasa
Network Administrator

do góry