"Vizvary II Istvan" <v...@p...onet.pl> writes:

>> Hasło *nie* musi być w całości w postaci jawnej. Patrz mój poprzedni
>> post <8...@l...localdomain>.
>
> To wobec tego powtarzam ci, że gdy sie podaje losową czesc hasła, to funkcje
> jednokierunkowe odpadają. Oczywiście możesz przechować wiele wyników funkcji
> dla dowoklnie wybranych kombinacji 5 znakowej z 10 znakowego hasła.W to z
> kolei ja nie wierze.
> Chociaż kto to wie ...

Nie dla dowolnej. Dla kilkuset ustalonych z góry (przy generowaniu).
Tylko to i tak kwestia zaufania (kto mi zagwarantuje, że system
informatyczny działa w tai, a nie inny sposób?).

--dżaf.

--
__ Maciek Pasternacki <m...@j...fnord.org> [ http://japhy.fnord.org/ ]
`| _ |_\ / { ...Can't you understand that the way things were planned
,|{-}|}| }\/ it never worked out, so I just went crazy... }
\/ |____/ ( Fish ) -><-

do góry

"Vizvary II Istvan" <v...@p...onet.pl> writes:

> Chociaż i tak caly atak kuleje.
> Potencjalny intruz od samego początku musiałby kontrolować i to w czasie
> rzeczywistym korespondencje elektroniczną klienta z centrum certyfikacji.
> Nie jest to łatwe, a nawet jesli sie uda, to atak padnie w momencie
> osobistej wizyty klienta w celu kontroli tozsamości. Trzeba by wybudować
> lipny oddział banku lub lipny punk rejestracji CA.

Mówiłem tu o bezpieczeństwie od strony czysto informatycznej. MITM
może wymaga sporych środków ze strony atakującego (możliwość
filtrowania połączeń na jednym z routerów po drodze albo IP
spoofing/hijacking), ale nie jest niemożliwe.

> zas dalej .... wybacz od tego jest grupa pl.comp.os.advocacy by podyskutowac
> sobie w kregu ekspertów (przepraszam za wyrazenie) nad wyzszoscia Linuxa nad
> Windowsami i odwrotnie.

Nie ja zacząłem. :p

> Ja po prostu twierdze, że jesli system operacyjny nie rozwiązał sprawę
> sprzętowego wspomagania kryptografii, tylko odpuszcza sprawe aplikacjom, to
> po prostu jest mało ambitny. Dobrze robi programistom. Czy klientom
> też...nie wiem.

Grr... czy fakt, że do sprzętowej kryptografii *jeszcze* nie ma
sterowników pod Linuksa (w co mi się nie chce wierzyć) znaczy, że
system jest gorszy? Kto Ci broni te sterowniki napisać? To jest
najwyżej kwestia czasu.


>> Wybacz, ale o ile rozumiem, sugerujesz
>> oddanie kontroli nad podpisami cyfrowymi jednej firmie prywatnej. Nie
>> bałbyś się?
>
> SUNowi bym się bal.
> AOLowi ? sprzedałbym szybciej komputer.
> MS - tu bym się zastanawiał. Przynajmniej pozwala klucze trzymac na kartach
> i nie narzuca własnej kryptografii. Zreszta żaden system nie narzuca.

Akurat MS jest znany jako firma, która nie narzuca własnych
rozwiązań. No comment. I EOT z mojej strony.


>> > zauwaz ile firm na tym zarobi (od TP S.A poczawszy)!
>>
>> Na tym -- czyli czym i w jaki sposób?
>
> O to chodzi, że jak sam zauważyłesz SSL jako zabezpieczenie (szczególnie
> jesli każdy może zmienić wygląd swojej przegladarki) to iluzja. Obrazek
> kłodki, napis https i wiara, że to działa.

Ale to działa. To znaczy, protokół od strony technicznej działa,
tylko trzeba stosować go z pewną świadomością tego, co się dzieje w środku.


> Jesli zakładamy , że użytkownik potrafi sie podpisać, to również może
> szyfrować dane. SAME DANE i bezpieczniej niż robi to SSL. Tak do banku jak
> do klienta.

Tu się zgodzę. Ale SSL nie jest fikcją polegającą na dodaniu przez
przeglądarkę literki ,,s'' do ,,http'' i kłódki w pasku stanu, bo jej
się tak uwidziało. SSL też daje silną kryptografię.


> A tak to obrazki i cała reszta idzie szyfrowany, złotówki leca, bo zegar
> tyka. Chociaż może i to nie jest taka istotna sprawa...

Hihi... akurat razem z włączeniem szyfrowania można AFAIK włączyć
dodatkową kompresję... jedno, co się traci, to cykle procesora,
których większość użytkowników posiada spory nadmiar.

Ale EOT.

--dżaf.

--
__ Maciek Pasternacki <m...@j...fnord.org> [ http://japhy.fnord.org/ ]
`| _ |_\ / { ...so I talked about conscience, and I talked about pain,
,|{-}|}| }\/ and he looked out of window, and it started to rain, and
\/ |____/ I thought, maybe - I've already gone crazy... } ( Fish ) -><-

do góry

"Maciek Pasternacki" <j...@h...org.pl> wrote in message
news:87bs8pruc2.fsf@lizard.localdomain...
> "Vizvary II Istvan" <v...@p...onet.pl> writes:
>
> > Chociaż i tak caly atak kuleje.
> > Potencjalny intruz od samego początku musiałby kontrolować i to w
czasie
> > rzeczywistym korespondencje elektroniczną klienta z centrum
certyfikacji.
> > Nie jest to łatwe, a nawet jesli sie uda, to atak padnie w momencie
> > osobistej wizyty klienta w celu kontroli tozsamości. Trzeba by
wybudować
> > lipny oddział banku lub lipny punk rejestracji CA.
>
> Mówiłem tu o bezpieczeństwie od strony czysto informatycznej. MITM
> może wymaga sporych środków ze strony atakującego (możliwość
> filtrowania połączeń na jednym z routerów po drodze albo IP
> spoofing/hijacking), ale nie jest niemożliwe.

Nie jest to dosłownie ŻADNE zagrożenie (albo bardzo łatwe do
wyeliminowania) w procesie generowania ządania certyfikatu.
Nie jest też to ŻADNA odpowiedz na moje argumenty, że zapomniałes w
opisie ataku uwzględnić takiego "drobiazgu" jak obecność gościa w
punkcie rejestracji.
Proponuję grupę pl.comp.security.


> > zas dalej .... wybacz od tego jest grupa pl.comp.os.advocacy by
podyskutowac
> > sobie w kregu ekspertów (przepraszam za wyrazenie) nad wyzszoscia
Linuxa nad
> > Windowsami i odwrotnie.
>
> Nie ja zacząłem. :p

Hmmm. To nie wiesz od czego się zaczęło, a sprawa jest zasadnicza.
Ty zacząłes proponując uzywac Linuxa jako panaceum na sprawy wiązane z
bezpieczeństwem po stronie klienta.
Ja z kolei twierdze, że postawienie Linuxa, nawet najlepiej
skonfigurowanego, za firewallem nie zapobiega opisanym przez Ciebie
atakom (MITM).
Za to uwzględnienie Linuxa jako stacji roboczej klienta w bankowości
elektronicznej DZIS (!) albo powoduje olbrzymy wzrost kosztow
opracowania i dystrybucji aplikacji, albo eliminuje sprzętowego
wspomagania kryptografii. Więc w efekcie własnie umożliwia opisany przez
Ciebie atak.

Sprawa jest na prawde skomplikowana i zasadnicza, ale mi tak na prawdę
chodzi tylko o nieprawdziwość twierdzenia jakoby postawienie Linuxa lub
Unixa w domu załatwi sprawę i nic więcej.

Vizvary

do góry

"Maciek Pasternacki" <j...@h...org.pl> wrote in message
news:87sn2a6w0s.fsf@lizard.localdomain...
> "Vizvary II Istvan" <v...@p...onet.pl> writes:
>
> > Wowczas kooprocesor kryptograficzny pobieral okolo 50 mA w czasie
obliczen
> > (teraz okolo 10 mA) i liczyl (RSA 1024 bit) okolo 3 sekund. (teraz
> > 300-700-1000 ms). To jest bardzo duzo dla urzadzenia bateryjnego. Na
tyle
> > duzo, ze czas pracy sie podaje nie w latach, tylko w ilosci
operacji. I to
> > bedzie niewiele operacji.
>
> A kto powiedział, że token musi być pancernie zamknięty i posiadać
> tylko okienko na wyświetlacz i ewentualnie guziczek? Zawsze można
> wprowadzić ładowanie. A żeby nie tracić kasy na ładowarki, dać
> przejściówkę do złącza baterii 9V (bo samo złącze byłoby
> niepraktyczne; chociaż, z jakąś zaślepką?) -- i ładować albo z
> baterii, albo z dowolnego zasilacza z takim wyjściem.

Tyle, że ja nie pisałem o tym co MOŻNABY, bo mozna i przewodem 5
milimetrowym podłaczyć do wózka akumulatorowego.
Ja pisałem o konkretnym tokenie, który wówczas widziałem. Albo i nie
widziałem, ale o nim usłyszałem. Już nie pamietam.
Zreszta moje założenia okazały się nieprawdziwe (jak kol. Halasa wykazał
wcale nie tak mało bedzie tych operacji) co nie zmienia faktu, że
wniosek wyciagnałem słuszny z tych błędnych przesłanek - token działał w
oparciu o pojedynczy DES.

Vizvary

do góry