Użytkownik "Krzysztof Halasa" <k...@d...pm.waw.pl> napisał w wiadomości
news:m3n0sy1mwe.fsf@defiant.pm.waw.pl...
> Ja ze swej strony polecam standardowo Handbook of Applied Cryptography
> (mimo ze nie jest to najnowsza ksiazka), potem mozna czytac inne rzeczy.

No, no, to jest chyba najlepsza cegła z tej dziedziny, ale pokazuje głównie
stronę teoretyczną kryptografii.

Pozdrawiam
Robert Wicik

do góry

"Piotr W" <t...@p...onet.pl> writes:

> 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 ;-)

Tego pierwszego, czy teog drugiego?

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

Nie wiem, kto generuje parę kluczy (Ty, czy bank - sensowniej byłoby,
gdybyś Ty sobie generował i wysyłał do banku tylko klucz publiczny),
ale jeden z kluczy zawsze musi być przesłany i tu jest właśnie
najwrażliwszy punkt. W wersji, w której bank generuje parę kluczy,
ktoś może podsłuchać po drodze klucz prywatny; w wersji, w której Ty
wysyłasz klucz publiczny do banku, ktoś może go po drodze podmienić.

SSL jest podatny na ataki typu MITM (Man In The Middle). Polega to,
wdużym skrócie, na tym, że atakujący siedzi gdzieć po drodze między
Tobą a bankiem i przedstawia się Tobie jako bank, a bankowi jako Ty.
Jako że autoryzacja w SSL opiera się na kluczach asymetrycznych, u
Ciebie, o ile masz włączone odpowiednie ustawienia, pokaże się okno,
że klucz banku się zmienił lub że nie jest certyfikowany -- napastnik
nie dysponuje kluczem prywatnym banku (chyba, że łączysz się z bankiem
po raz pierwszy, wtedy - sorry, Winnetou). Ogromna większość ludzi w
takiej sytuacji klika ,,OK'' i łączy się dalej... Wniosek: trzeba
przy sprawdzać fingerprint klucza banku (widać go gdzieś w ,,opcjach
zabezpieczeń'', o ile pamiętam) i nie klikać ,,OK'' na wszystkich
okienkach. Prawidłowy fingerprint klucza powinien być udostępniony na
stronie banku... tylko, z drugiej strony, jeżeli ktoś może przedstawić
Ci się jako bank, nie stanowi dla niego problemu podstawienie nieco
zmienionej strony (ze swoim fingerprintem). Problem prędzej czy
później sprowadza się do bezpiecznego przekazania klucza. Z
fingerprintem klucza SSL-owego jest o tyle łatwiej, że (teoretycznie)
powinieneś móc zapytać pracownika banku, albo bank mógłby go drukować
na ulotkach, reklamach itp... jak to u nas wygląda w praktyce -
wiadomo... :(

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

Dobry antywir, dobry (i dobrze skonfigurowany) firewall, dobra
przeglądarka i klient maila (czytaj: jak chcesz mieć bezpiecznie,
zapomnij o Explorerze i Outlooku). Plus, w ramach dodatkowej paranoi,
szyfrowanie we własnym zakresie co wrażliwszych plików. A najlepiej
to nie korzystać z windowsów, tylko postawić (dobrze skonfigurowanego)
Linuksa/BSD/dowolnego innego Uniksa.

Pozdrawiam,
--japhy

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

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

> "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 ?
>

A taki system: generując karteczkę z hasłami, system losuje dajmy na
to 2000 kombinacji znaków z karteczki, zapisuje w pliku kombinację
(numery znaków) i hash kombinacji, po czym zapomina pierwotną kartkę?
Przy każdym logowaniu losuje jedną z ustalonych wcześniej kombinacji,
sprawdza ją i skreśla z listy. Jak zostanie mniej niż połowa, każe
wygenerować nową karteczkę.

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

Tu się zgodzę. Niezależnie od implementacji, hasła jednorazowe (czy
dowolne inne hasła tudzież cokolwiek nie opartego na kluczach
asymetrycznych) nie będzie stuprocentowo niezaprzeczalne. Tym
bardziej, że nigdy nie mam pewności, że bank nie skopiował sobie
gdzieś czystej wersji haseł.

--japh

--
__ Maciek Pasternacki <m...@j...fnord.org> [ http://japhy.fnord.org/ ]
`| _ |_\ / { ...więc chwytam kraty rozgrzane do białości, twarz moją widzę,
,|{-}|}| }\/ twarz przekleństwa, a obok sąsiad patrzy z ciekawością,
\/ |____/ jak płonie na nim kaftan bezpieczeństwa... } ( J. Kaczmarski ) -><-

do góry

Krzysztof Halasa <k...@d...pm.waw.pl> writes:
>> 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?

Znajomość otwartych systemów haseł jednorazowych (OPIE, S/KEY, OTPW),
podstawowa znajomość zagadnień bezpieczeństwa informatycznego i
odrobina zdrowego rozsądku. Chyba, że przeceniam nasze banki...

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

...tak, chyba przeceniam. Byłem święcie przekonany, że jak hasło jest
jednorazowe i czytane z karteczki, to można wymagać od ludzi
przepisania co najmniej siedmiu znaków, liter (małych i dużych) i
cyfr. Co byłoby i tak niezbyt złożonym hasłem...

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

Chyba, że wymyślili coś sprytnego. W co nie wierzę. (hm... token
oparty w jakiś sposób na algorytmie w duchu S/KEY?)

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

Albo mi się coś pochrzaniło przy przepisywaniu, albo Ty odczytałeś nie
w tę stronę; w każdym razie, miałem na myśli właśnie S/KEY.

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

Ja po prostu chyba jakiś naiwny jestem i zakładam, że klucze mają
jakiś ludzki rozmiar.

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

Możesz rozwinąć? Chodzi Ci o to, że to, co mi wypluwa np. md5sum
,,wygląda inaczej''? Przecież hasz czegokolwiek jest liczbą, a to, co
wypluwa md5sum albo jest zapisane w /etc/shadow jest jakąś
reprezentacją alfanumeryczną tej liczby. Co komu szkodzi hashować tym
samym algorytmem, używając innej reprezentacji liczb? Chyba, że źle
zrozumiałem...

--japh

--
__ Maciek Pasternacki <m...@j...fnord.org> [ http://japhy.fnord.org/ ]
`| _ |_\ / { ...Boże Ciało. Pół rynku, albo trzy czwarte rynku,
,|{-}|}| }\/ oblepione wiernymi. Czemuś jestem wierny,
\/ |____/ więc czuję się u siebie... } ( M. Świetlicki ) -><-

do góry

"Maciek Pasternacki" <j...@h...org.pl> wrote in message
news:871ya9tgu1.fsf@lizard.localdomain...
> > 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 ?
> >
>
> A taki system: generując karteczkę z hasłami, system losuje dajmy na
> to 2000 kombinacji znaków z karteczki, zapisuje w pliku kombinację
> (numery znaków) i hash kombinacji, po czym zapomina pierwotną kartkę?
> Przy każdym logowaniu losuje jedną z ustalonych wcześniej kombinacji,
> sprawdza ją i skreśla z listy. Jak zostanie mniej niż połowa, każe
> wygenerować nową karteczkę.

Nie bardzo rozumie, ale poki bank i klient sobie ufaja (i wszystkim swoim
pracownikom jak tez dowolnemu ich zespolowi) bezwzglednie, wydaje się, że
bedzie to niewatpliwie bardzo bezpieczne. (Ale czy niezaprzeczalne i
wystarczajaco wiarygodne np. dla sadu w razie sporu?)


Vizvary

do góry

"Maciek Pasternacki" <j...@h...org.pl> wrote in message
news:87wus1s272.fsf@lizard.localdomain...
> Krzysztof Halasa <k...@d...pm.waw.pl> writes:
> >> 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?
>
> Znajomość otwartych systemów haseł jednorazowych (OPIE, S/KEY, OTPW),
> podstawowa znajomość zagadnień bezpieczeństwa informatycznego i
> odrobina zdrowego rozsądku. Chyba, że przeceniam nasze banki...

Ponownie Ci zwracam uwage na przyadek BS Online - do identyfikacji podaje
się CZESC hasla. Funkcja skrotu wykluczona. Haslo MUSI byc w banku w postaci
jawnej. Inna sprawa, że owe haslo upowaznia do sprawdzenia stanu konta itd.
Do wszelkich operacji stosuja podpisane cyfrowo dokumenty.

> Chyba, że wymyślili coś sprytnego. W co nie wierzę. (hm... token
> oparty w jakiś sposób na algorytmie w duchu S/KEY?)

Roznie z tym bywa. Ja się krecilem wokol zespolu ktory wdrazal pierwsze
tokeny w Polsce (w innej sprawie). Z tego co pamietam i wiem, kierownictwo
banku zazadal tokeny z kryptografii asymetryczna. Producent tokenu
zapewnial, ze dostarczane tokeny beda takie. Mi sie smiac chcialo i
tlumaczylem ze wykluczone, by moglo takie cos miec zasilanie bateryjkowe i
to dzialajace bez wymiany baterii przez dwa lata (znajac pobor mocy kart z
kryptografia asymetryczna). Czas naglil. Okazalo sie, że tokeny zawieraja
pojedynczy DES i to bodajze DES okrojony ze wzgledu na ograniczenia
eksportowe...


Vizvary

do góry

"Maciek Pasternacki" <j...@h...org.pl> wrote in message
news:877kk1th7f.fsf@lizard.localdomain...
> w której Ty
> wysyłasz klucz publiczny do banku, ktoś może go po drodze podmienić.

I co z nim robi ? A tak na prawde klucz publiczny wysyla sie w postaci
standardowego zadania certyfikatu w postaci podpisanej kluczem prywatnym.
Mozna jeszcze szyfrowac kluczem publicznym serwera certyfikatow.


> SSL jest podatny na ataki typu MITM (Man In The Middle).
[...]
>Polega to, [...] jak to u nas wygląda w praktyce - wiadomo... :(

SSL przyjelo sie traktowac jako narzedzie zapewniajace bezpieczenstwo. Dla
mnie jest ono kiepskim narzedziem nadającym sie w ograniczonym zakreesie do
zapewnienia prywatności (szyfrowanie).

> > trojany , sniffery . . .
> > czy dobry antywiral , i bezwzględny brak dostępu osób trzecich
> > są w stanie zabezpieczyc skutecznie komp
> > No . . . prawie
>
> Dobry antywir, dobry (i dobrze skonfigurowany) firewall, dobra
> przeglądarka i klient maila (czytaj: jak chcesz mieć bezpiecznie,
> zapomnij o Explorerze i Outlooku). Plus, w ramach dodatkowej paranoi,
> szyfrowanie we własnym zakresie co wrażliwszych plików. A najlepiej
> to nie korzystać z windowsów, tylko postawić (dobrze skonfigurowanego)
> Linuksa/BSD/dowolnego innego Uniksa.
>
> Pozdrawiam,
> --japhy

Musze Cie rozczarowac. Zupelnie co innego jest stabilny serwer internetowy,
a co innego jest stacja robocza.

Prosty przyklad - ochrona przed administratorem. Czy glowny ksiegowy
korporacji moze byc pewny, ze rano zastaje TEN SAM system operacyjny, ktory
wczoraj wylaczyl ? A moze ktos mu w nocy "przekompilowal jadro"? To samo
dotyczy wiekszosc oprogramowania OpenSource. Sprawa bynajmniej nie jest
jednoznaczna.

Podobnie wyglada sprawa bezpieczenstwa komunikacji.

Wez pod uwage nastepujaca rzecz.
W 1997 wspolne przedsiewziecie MS Sun i IBM (PCSC Workgroup) opracowalo
zasady wlaczenia kryptografii asymetrycznej (i obsluge kart
kryptograficznych) w systemy operacyjne.
MS konsekentnie realizuje, tak, że dzis szyfrowanie i podpis cyfrowy
dokumentow elektronicznych to dwie linii kodu w IE. Dotyczy to rowniez
szyfrowanie i podpis przez karty kryptograficzne. Jest to zawarte w cenie
systemu operacyjnego i przegladarki.
Sun i IBM po roku sie wylamaly, utworzyly konkurencyjny OpenCard Framework i
w zeszlym roku zakonczyly prace - niczym (PO PROSTU!) .
Efekt jest taki, że wspomniane problemy z SSL dotycza wspomniany przez
Ciebie Linux/BSD/Unix.
Jesli zas dotyczy Windows, to TYLKO dlatego, że ze wzgledu na wrazliwosc
uzytkownikow innych przegladarek i systemow operacyjnych niz od MS- nikomu
do glowy nie przyjdzie wykorzystac to, co juz jest gotowe w IE. Zreszta
zauwaz ile firm na tym zarobi (od TP S.A poczawszy)!

Vizvary

do góry

Użytkownik Maciek Pasternacki <j...@h...org.pl> w wiadomości do grup
dyskusyjnych napisał:8...@l...localdomain...
> "Piotr W" <t...@p...onet.pl> writes:
>
> >> 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 ;-)
> Tego pierwszego, czy teog drugiego?
> --japhy

pierwszego ... niestety :-(


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

do góry

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

> SSL jest podatny na ataki typu MITM (Man In The Middle). Polega to,
> wdużym skrócie, na tym, że atakujący siedzi gdzieć po drodze między
> Tobą a bankiem i przedstawia się Tobie jako bank, a bankowi jako Ty.
> Jako że autoryzacja w SSL opiera się na kluczach asymetrycznych, u
> Ciebie, o ile masz włączone odpowiednie ustawienia, pokaże się okno,
> że klucz banku się zmienił lub że nie jest certyfikowany -- napastnik
> nie dysponuje kluczem prywatnym banku (chyba, że łączysz się z bankiem
> po raz pierwszy, wtedy - sorry, Winnetou).

To nie tak. Normalnie userowi ostrzezenie pokaze sie wtedy, jesli
serwer nie ma certyfikatu wydanego przez jakikolwiek CA wpisany
w konfiguracji przegladarki (albo zaszyty w tajnym miejscu w kodzie,
kto to moze wiedziec). Oczywiscie ostrzezenie bedzie takze wtedy,
jesli certyfikat nie bedzie odpowiedni z jakiegokolwiek powodu.

> Ogromna większość ludzi w
> takiej sytuacji klika ,,OK'' i łączy się dalej... Wniosek: trzeba
> przy sprawdzać fingerprint klucza banku (widać go gdzieś w ,,opcjach
> zabezpieczeń'', o ile pamiętam) i nie klikać ,,OK'' na wszystkich
> okienkach. Prawidłowy fingerprint klucza powinien być udostępniony na
> stronie banku... tylko, z drugiej strony, jeżeli ktoś może przedstawić
> Ci się jako bank, nie stanowi dla niego problemu podstawienie nieco
> zmienionej strony (ze swoim fingerprintem). Problem prędzej czy
> później sprowadza się do bezpiecznego przekazania klucza.

W takim scenariuszu system certyfikatow jest zbedny, wystarczylyby
same klucze (dystrybucja kluczy publicznych). Takie cos sie sprawdza,
ale raczej w innych okolicznosciach.
--
Krzysztof Halasa
Network Administrator

do góry

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

> Znajomość otwartych systemów haseł jednorazowych (OPIE, S/KEY, OTPW),
> podstawowa znajomość zagadnień bezpieczeństwa informatycznego i
> odrobina zdrowego rozsądku. Chyba, że przeceniam nasze banki...

Nie, to nawet nie o to chodzi. Tego nie da sie tak zrobic "dla mas".

> > 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.
>
> ...tak, chyba przeceniam. Byłem święcie przekonany, że jak hasło jest
> jednorazowe i czytane z karteczki, to można wymagać od ludzi
> przepisania co najmniej siedmiu znaków, liter (małych i dużych) i
> cyfr. Co byłoby i tak niezbyt złożonym hasłem...

Wlasnie. Dla osoby, ktora wlamala sie do domu z wlaczonym komputerem
i strona z np. mBanku roznica miedzy takimi haslami i 5-znakowymi
bedzie niezauwazalna (bo albo wlamywacz znajdzie kartke z haslami,
albo jej nie znajdzie i najwyzej zasili zaklad energetyczny).
Dla komputera, ktory mialby to polamac, roznica bedzie oczywiscie
wielokrotna - ale i tak zajmie to tylko chwile.

> Chyba, że wymyślili coś sprytnego. W co nie wierzę. (hm... token
> oparty w jakiś sposób na algorytmie w duchu S/KEY?)

Teoretycznie moglaby byc taka mozliwosc, ale:
- 1. wciaz problem dlugosci klucza
- 2. user musialby sam "obsiewac" taki token (ten sam problem co przy
kryptografii asymetrycznej).

No i ile normalne tokeny maja nieograniczony czas zycia (przynajmniej
nie jest z zalozenia ograniczony), a poza tym zabezpieczaja usera przed
"skopiowaniem wskazan".

> Ja po prostu chyba jakiś naiwny jestem i zakładam, że klucze mają
> jakiś ludzki rozmiar.

Tzn. ile? Ludzie maja sklonnosc do uzywania slabych kluczy (entropia
w wymyslanych przez nich haslach to cos w stylu np. 2 bitow / znak).
Hasla generowane losowo przez komputer sa oczywiscie lepsze, ale
trudniejsze do zapamietania/zapisania, i naprawde nie moga byc
specjalnie dlugie, jesli maja dzialac (postaw sie w sytuacji helpdesku).

> > 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.
>
> Możesz rozwinąć? Chodzi Ci o to, że to, co mi wypluwa np. md5sum
> ,,wygląda inaczej''? Przecież hasz czegokolwiek jest liczbą, a to, co
> wypluwa md5sum albo jest zapisane w /etc/shadow jest jakąś
> reprezentacją alfanumeryczną tej liczby. Co komu szkodzi hashować tym
> samym algorytmem, używając innej reprezentacji liczb? Chyba, że źle
> zrozumiałem...

Tak przypuszczam. Taki hash MD5 zapisany w postaci dziesietnej mialby
tylko ok. 128/10*3 = czterdziesci cyfr. Przy SHA1 tylko drobne 50 cyferek.

No coz, w jakims sensie to tez wyglada inaczej :-)
--
Krzysztof Halasa
Network Administrator

do góry