> Jednak na razie, dopoki nie ma porzadnie zrealizowanego (i
> zastosowanego w bankowosci internetowej) podpisu na karcie
> kryptografciznej, osobiscie wole zabezpieczenia oparte na TANach lub
> tokenach (mimo zagrozen opisanych dokladnie przez Vizvardego).

To nie jest kwestia woli klienta. Po prostu jesli sie wymaga
niezaprzeczalnosc transakcji ze strony klienta, to nie ma innej drogi niz
taki czy inny sposob realizacji podpisu cyfrowego.
Rozum - to nie jest kwestia ZABEZPIECZENIA, tylko dokładny rozdział
odpowiedzialnosci, niezaprzeczalnosc transakcji i podpisanie umow na
odległosc. Zupelnie inne funkcje, niz zapewnienie poufnosci pomiedzy
stronami, ktore sobie w założeniach ufaja, bo posluguja sie umowionymi i
znanymi obu stronom sygnałami (hasla jedno i wielorazowe lub wskazanie
topkena).
I zeby nie bylo nieporozumienia - w zaden sposob nie proponuje zastapic
tokeny czy tany karta (chyba, że bedzie to jedna dodatkowa funkcja jakiejs
karty, wiec nijako "przy okazji"). Tam gdzie tokeny lub TANy wystarczaly,
tam podejrzewam ze wystarczaja jeszcze długo.

Vizvary

do góry

> > A tu podstawowy problem - podpisał Kowalski, czy ktoś kto akurat był w
> > posiadaniu kluczy Kowalskiego, dlatego trzeba chronić klucze.
> Albo dodatkowo zabezpieczać urządzenia/procedury PIN-em lub
> identyfikacją biometryczną.

Kilka lat temu mialem taki ulubiony (chociaz makabryczny) przyklad na
zastosowanie identyfikacji biometrycznej czy do podpisu czy do odblokowania
urzadzenia podpisujacego - delikwent po wypadku jeszcze ostatnim wysilkiem
zdazylby przelac swoje oszczednosci na rzecz personelu karetki. Od roku wole
tym przykladem sie nie poslugiwac (szczegolnie ze pisze to z Lodzi) ale
zwroc uwage, że podpis cyfrowy powinno byc WYRAZEM WOLI, wiec cos, co
pozbawiony swiadomosci klient nie jest w stanie dokonac. Wiec cos co wie.
oki co pozostanie PIN kod lub (na przyklad) hasla jednorazowe.

> > Kopia zapasowa
> > kluczy może się jeszcze znajdować w instytucji je generującej na wypadek
np.
> > odtworzenia w przypadku zagubienia ...
>
> To chyba nawet w ustawie zostało przewidziane.

Tak? Gdzie?

Vizvary

do góry

A po co wykreślać SMS ? Przecież to kanał pasywny (mBank).
Ardi

do góry

Użytkownik Ardi <a...@g...pl> w wiadomości do grup dyskusyjnych
napisał:agfkps$jbb$...@k...task.gda.pl...
> A po co wykreślać SMS ? Przecież to kanał pasywny (mBank).
> Ardi
>
>
jak masz stały dostęp do PC :-)

--
Piotr W
t...@p...onet.pl

do góry

Użytkownik Maciek Pasternacki <j...@h...org.pl> w wiadomości do grup
dyskusyjnych napisał:8...@l...localdomain...
> W podpisie elektronicznym masz do czynienia z tzw. kluczem prywatnym i
> publicznym. Klucz prywatny masz tylko ty, klucz publiczny zna cały
> swiat

tego nigdy nie można być pewnym ;-)

> W przypadku podpisu elektronicznego hasło, ani żadna inna wrażliwa
> wiadomość, nie jest przesyłana przez sieć przy każdej transakcji (ani
> w postaci czystej, ani w zaszyfrowanej), bo autoryzacja nie opiera się
> na znajomości wspólnego sekretu (hasła), tylko na posiadaniu
> odpowiednich połówek sekretu (klucza publicznego i prywatnego).

mam jednak wątpliwości czy przesyłanie klucza prywatnego
w trakcie jego nadania przez i-net nie umożliwia jego przechwycenie
( mimo że przekaz szyfrowany SSL )

> Trojan nie przechwyci hasła z sieci (to robią sniffery)
> --japhy
> __ Maciek Pasternacki <m...@j...fnord.org>
http://japhy.fnord.org/ ]

trojany , sniffery . . .
czy dobry antywiral , i bezwzględny brak dostępu osób trzecich
są w stanie zabezpieczyc skutecznie komp
No . . . prawie

--
Piotr W
t...@p...onet.pl

do góry

On Thu, 11 Jul 2002 10:28:42 +0200, "Piotr W" <t...@p...onet.pl>
wrote:
>
>trojany , sniffery . . .
>czy dobry antywiral , i bezwzględny brak dostępu osób trzecich
>są w stanie zabezpieczyc skutecznie komp
>No . . . prawie

I jeszcze firewall, no i ostrozne dawanie uprawnien programom, kotre o
nie prosza
--
Wojtek Frabinski ICQ 50443653
w...@a...net.pl
Moja strona Meat Loafa http://www.meatloaf.3a.pl/
galeria kart bankowych http://www.karty.3a.pl/

do góry

Wojtek Frabinski wrote:

> >trojany , sniffery . . .
> >czy dobry antywiral , i bezwzględny brak dostępu osób trzecich
> >są w stanie zabezpieczyc skutecznie komp
> >No . . . prawie
>
> I jeszcze firewall, no i ostrozne dawanie uprawnien programom, kotre o
> nie prosza

i to nie gwarantuje 100% bezpieczenstwa, jesli ktos sie uprze to
podrzuci trojana ktory bardzo skutecznie podszyje sie pod jakies
uslugi systemowe

do góry

Użytkownik "Piotr W" (.................)
> mam jednak wątpliwości czy przesyłanie klucza prywatnego
> w trakcie jego nadania przez i-net nie umożliwia jego przechwycenie
> ( mimo że przekaz szyfrowany SSL )

nikt ci nie "nadaje" klucza prywatnego i nie przesyla go przez siec.
klucz ten jest generowany przez przegladarke, inne oprogramowanie zainstalowane
lokalnie lub procesor krryptograficzny na karcie chipowej. W tym ostatnim
przypadku zostaje on na karcie i nigdy jej nie opuszcza bo nawet ty sam jako
wlasciciel nie musisz go znac ;-))
*** blad ***

do góry

"Maciek Pasternacki" <j...@h...org.pl> wrote in message
news:87k7o58f27.fsf@lizard.localdomain...

> Nieprawda. To znaczy, bank (o ile nie są skrajnymi kretynami ani
> niczym w tym duchu) nie posiada odszyfrowanej listy moich haseł
> jednorazowych, tylko (w prostszym przypadku) jednokierunkowe funkcje
> skrótu każdego z tych haseł.

Hmmmm. Ja bym ostrozniej operowal takimi pojeciami jak "nieprawda". Wezmy
dla przykładu BSK Online czy jak sie teraz nazywa. Ja podaje czesc hasla (5
wytypowanych przez system znakow). Znasz taka funkcje hashujaca, ktora
potrafi z czesci tekstu robic jednakowy skrot? Czy raczej jest to dowod, ze
haslo jest w postaci czystej przechowane ?



>W ciekawszej implementacji haseł [...]

Niezaleznie od tego w jaki sposob jest, czy jest czy nie jest implementowane
i co jest implementowane ....
Poki klient nie autoryzuje kazdej tranzakcji dokumentem niepodrabialnym ale
tez niezaprzeczalnym a bank sie nie zobowiazuje kazdej transakcji klienta
takim czyms dokumentowac, tak dlugo w pewnym sensie mamy do czynienia
bankowoscia "na slowo honoru". Co wcale nie wyklucza pozytecznosci (i
stosowania z pewnymi ograniczeniami co do dopuszczalnych operacji.) bo w ten
sposob konstruowane systemy zapewniają dużą mobilność uzytkownika. Wiekszą ,
niż systemy oparte o podpis cyfrowy. Jakie operacje dopuszczac i z jakimi
ograniczeniami, to zalezy od kalkulacji ryzyka.

Vizvary

do góry

Maciek Pasternacki <j...@h...org.pl> writes:

> Nieprawda.

Jednak prawda.

> To znaczy, bank (o ile nie są skrajnymi kretynami ani
> niczym w tym duchu) nie posiada odszyfrowanej listy moich haseł
> jednorazowych, tylko (w prostszym przypadku) jednokierunkowe funkcje
> skrótu każdego z tych haseł.

1. Skad ta informacja?
2. Taki mechanizm, by sensownie dzialac, potrzebuje argumentu o znacznej
dlugosci. Przy kilku cyfrach takiego hasla jednorazowego, nie ma
najmniejszego znaczenia czy bank przechowuje skrot, czy cale haslo
- i tak zlamanie tego trwa mikrosekunde.

Dokladnie tak samo jest oczywiscie z tokenami, tyle ze tam bank musi
posiadac kompletne dane o pamieci tokena, gdyz musi z nich na biezaco
liczyc jego wskazania.

> W ciekawszej implementacji haseł
> jednorazowych, każde kolejne hasło jest jednokierunkową funkcją skrótu
> poprzedniego, a bank (czy cokolwiek innego dokonującego autoryzacji)
> posiada tylko wartość jednokierunkowej funkcji skrótu ostatniego
> hasła. Ja podaję ostatnie hasło z listy, bank sprawdza, czy wartość
> funkcji skrótu jest taka sama, jeżeli tak, zapamiętuje podane przeze
> mnie hasło (już użyte, czyli tym samym odtajnione) jako wartość
> funkcji skrótu hasła kolejnego.

Niczego takiego sie nie stosuje. Gdyby tak bylo, bank moglby wygenerowac
kazde haslo (ktore jest skrotem poprzedniego). S/Key dziala dokladnie
odwrotnie - stare haslo jest funkcja nowego, po prostu hasla podaje sie
w odwrotnej kolejnosci do ich generowania.

Nie slyszalem, by jakis bank uzywal tego mechanizmu. Co oczywiscie nie
ma zadnego znaczenia, gdyz nie jest on z zalozenia bezpieczny
kryptograficznie przy niewielkich rozmiarach kluczy.

> Nie wiem, jak wyglądają algorytmy
> tokenów, tutaj już jest większe prawdopodobieństwo, że bank posiada
> dokładnie tę samą tajemnicę (chyba, że wymyślili coś równie sprytnego,
> jak powyżej); token działa głównie na zasadzie ,,security by
> obscurity'', a jak wszyscy (mam nadzieję) wiedzą, ,,security by
> obscurity is no security''.

Nie, token dziala na zasadzie jawnego algorytmu i shared secret (seed).
Przynajmniej od jakiegos czasu tokeny SecurID tak dzialaja, wczesniej
algorytm takze byl niby tajny (na tyle, na ile tajny przed adminem
serwera autoryzacyjnego moze byc jakis kod).

> Jednokierunkowa funkcja skrótu to jest taka funkcja, której
> odwrotności nie można obliczyć (a konkretniej, złożoność obliczeniowa
> odwrotności takiej funkcji jest większa niż metoda brute force --
> wyliczanie wartości funkcji kolejno dla wszystkich możliwych danych
> wejściowych). Funkcjami takimi są np. algorytm MD5, SHA1 czy uniksowy
> crypt().

To teraz porownaj np. SHA1 czy nawet MD5 (ktory jest podatny na ataki
polegajace na dopasowywaniu tresci do pozadanego wyniku) z tym, co
wklepujesz w okienko logowania / potwierdzenia przelewu itp.

> Zainteresowanym polecam cegiełkę ,,Kryptografia dla praktyków'' pana
> Bruce'a Schneiera.

Ja ze swej strony polecam standardowo Handbook of Applied Cryptography
(mimo ze nie jest to najnowsza ksiazka), potem mozna czytac inne rzeczy.
--
Krzysztof Halasa
Network Administrator

do góry