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

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

To akurat bylo to, czego nalezalo sie spodziewac.
Ale moc nie powinna tu byc jakims wyznacznikiem - w koncu mozna zrobic
tak, ze token bedzie pracowal tylko wtedy, gdy jest cos do zrobienia.
Zreszta sa takie tokeny, nie wyswietlaja normalnie nic, dopiero po
nacisnieciu klawisza. Naturalnie jakis tam RTC pracuje caly czas,
ale to nie problem dla baterii litowej.
--
Krzysztof Halasa
Network Administrator

do góry

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

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

Hasło *nie* musi być w całości w postaci jawnej. Patrz mój poprzedni
post <8...@l...localdomain>.

Inna sprawa, że to jest tak czy inaczej kwestia zaufania. Ale do
wprowadzenia w .pl porządnych podpisów cyfrowych, to się raczej nie
zmieni...

--japh

--
__ Maciek Pasternacki <m...@j...fnord.org> [ http://japhy.fnord.org/ ]
`| _ |_\ / { ...nazwy serwerów poczty wychodzącej i przychodzącej
,|{-}|}| }\/ są jak grupa krwi. Trzeba zawsze mieć to gdzieś zapisane
\/ |____/ i zawsze przy sobie. } ( J. L. Wiśniewski ) -><-

do góry

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

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

Zachowa dla siebie. A bankowi przedstawi swój klucz publiczny
(podpisany swoim kluczem prywatnym) jako Twój.


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

SSL jest całkiem niezłym narzędziem zapewniejącym bezpieczeństwo
informacji podczas przesyłania (zabezpieczenie zarówno przed atakami
aktywnymi, jak i pasywnymi). O ile tylko używa się tego świadomie,
wiedząc co się robi i nie klikając ,,Tak'' w każdym oknie, które się
pokaże. Problem tkwi w tym, że większość ludzi wychodzi z założenia,
że jak przy tym ,,http'' w okienku jest jeszcze ,,s'', to znaczy, że
jest bezpiecznie -- taki magiczny warunek wystarczający
,,bezpieczeństwa'' dla kogoś, kto nie potrafiłby zdefiniować, na czym
to bezpieczeństwo powinno polegać.

>> 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.
>
> Musze Cie rozczarowac. Zupelnie co innego jest stabilny serwer internetowy,
> a co innego jest stacja robocza.

Ja mam stację roboczą na Linuksie. Wiem, co jest w przeglądarce
internetowej, czytniku maila itd. W razie potrzeby mogę zmienić, co
mi się żywnie podoba. Wiem, że wysypanie się jednego programu nie
położy mi całego systemu -- ani jednorazowo (zwis), ani permanentnie
(uszkodzenie ważnych plików). Temu systemowi mogę zaufać, bo *widzę*,
co ma w środku i mogę go dostosować do swoich potrzeb, nawet
najbardziej paranoicznych.

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

A czy mając Windowsa w jakiejkolwiek sieci ma pewność, że mu się nie
przypałętał robak-trojan, wpięty w przeglądarkę i wysyłający zawartość
wszystkich formularzy z polem ,,Hasło'' do Mossadu / CIA / Al Kaidy /
/ konkurencji?

> Podobnie wyglada sprawa bezpieczenstwa komunikacji.

Wybacz, ale najbliższym routerem brzegowym też ktoś musi
administrować. A sniffera dużo łatwiej ukryć w Windowsie niż w
U*ksie.

> 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

Jakiego kodu? W źródłach IE? Kodu JavaScript / VBScript / cokolwiek
w dokumencie HTML?

> szyfrowanie i podpis przez karty kryptograficzne. Jest to zawarte w cenie
> systemu operacyjnego i przegladarki.

Wysyłanie do Microsoftu informacji o tym, jakie strony oglądam, też.
Bez możliwości zablokowania, jaką miałbym w OpenSource, nawet jakby
komuś przyszło do głowy zbierać takie statystyki bez możliwości
wyłączenia tego w konfiguracji. W co nie wierzę.

> Efekt jest taki, że wspomniane problemy z SSL dotycza wspomniany przez
> Ciebie Linux/BSD/Unix.

Co ma SSL do podpisów cyfrowych kartą kryptograficzną? Poza tym:
podatność na ataki MITM są cechą *protokołu*, a nie którejś jego
konkretnej implementacji.

> 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

Mam rozumieć, że wszyscy programiści według Ciebie albo mają płacić
haracz Microsoftowi za ich rozwiązania i zamykać kod źródłowy (bo to
przecież zastrzeżone algorytmy), albo dać sobie spokój z
programowaniem kryptografii? Wybacz, ale o ile rozumiem, sugerujesz
oddanie kontroli nad podpisami cyfrowymi jednej firmie prywatnej. Nie
bałbyś się?

> zauwaz ile firm na tym zarobi (od TP S.A poczawszy)!

Na tym -- czyli czym i w jaki sposób?

--japh

--
__ Maciek Pasternacki <m...@j...fnord.org> [ http://japhy.fnord.org/ ]
`| _ |_\ / { ...człowiek myślący jest solą w oku.
,|{-}|}| }\/ Kretyn to kretyn. Dajcie mu spokój... }
\/ |____/ ( J. Kofta ) -><-

do góry

Krzysztof Halasa <k...@d...pm.waw.pl> writes:

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

Dlaczego?

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

Mówiąc o łamaniu haseł chyba nie mamy na myśli włamywacza znajdującego
kartkę z hasłami, bo to jest oczywiste, że wtedy długość hasła nie ma
znaczenia. Dlatego do jednorazów powinien być jakiś stały pin czy
prefix password jak w OTPW. Dla programu łamiącego... hm... weźmy
pięciocyfrową liczbę. Mamy ln 10/ln 2 = 3,322 bita na cyfrę, razy
pięć to będzie 16,6 bitów na hasło. Przy siedmiu znakach
litery/cyfry, mamy ln (26*2+10 = 62)/ln 2=5,954 bitów na znak, razy
siedem to jest 41,68 bitów na hasło. Rzeczywiście, wciąż mało jak na
dzisiejszą moc obliczeniową. Chociaż, jak na jednorazy w systemie
OTPW, gdzie szansę trafienia możesz mieć jak jeden do kilkuset tysięcy
(wspomniany wyżej system z wybieraniem iluś cyfr z długiej tabeli może
być jakimś słabszym wariantem OTPW, co zresztą wcześniej opisałem).


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

To nie była jakakolwiek sugestia z mojej strony, raczej taka dość
losowa myśl.


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

Jak są jednorazowe (ze zdrapką), to nawet nie trzeba
,,wygwiazdkowywać'' pola do wpisywania hasła. W hasłach
jednorazowych, paradoksalnie można osiągnąć większą entropię
pojedynczego hasła niż w hasłach ,,zwykłych''.

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

A kto mi (a właściwie bankowi) zabroni wygenerować 64-, 48-, a nawet
32-bitowy skrót SHA1 albo MD5? Że zamiast 128 bitów entropii będą 64?
Do jednorazów wystarczy. Powtarzam, nie widziałem rozwiązań haseł
jednorazowych stosowanych przez banki, byłem przekonany, że nie
stosują rozwiązań, które bym obśmiał, jakby ktoś mi sugerował
zabezpieczenie tym konta pocztowego, a co dopiero dorobku całego
życia... ;)

Pozdrawiam,
--Washington Irving

--
__ Maciek Pasternacki <m...@j...fnord.org> [ http://japhy.fnord.org/ ]
`| _ |_\ / { ...For I was born with a habit, from a sign,
,|{-}|}| }\/ the habit of a windswept thumb,
\/ |____/ and a sign of the rain... } ( Fish ) -><-

do góry

"Krzysztof Halasa" <k...@d...pm.waw.pl> wrote in message
news:m3znwr8ukt.fsf@defiant.pm.waw.pl...

> Ale moc nie powinna tu byc jakims wyznacznikiem - w koncu mozna zrobic
> tak, ze token bedzie pracowal tylko wtedy, gdy jest cos do zrobienia.

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.

Vizvary

do góry

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

Ale na tyle wiele, zeby wystarczylo na dlugo. Czy potrzebujesz czegos
wiecej?

No chyba ze to mialo sluzyc do wielu operacji dziennie.
--
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".
>
> Dlaczego?

Poniewaz masy wola 5-cyfrowe hasla jednorazowe itp. Poniewaz masy
nie sa w stanie wklepac np. do telefonu 128-bitowego hasha MD5.
Poniewaz tak naprawde w tej chwili to nie wystarczy, by zabezpieczyc
sie przed dzialaniem banku na szkode klienta. Poniewaz to i tak byloby
rozwiazanie przejsciowe - wszyscy czekaja na podpis elektroniczny,
i sie z pewnoscia doczekaja.

> Mówiąc o łamaniu haseł chyba nie mamy na myśli włamywacza znajdującego
> kartkę z hasłami, bo to jest oczywiste, że wtedy długość hasła nie ma
> znaczenia. Dlatego do jednorazów powinien być jakiś stały pin czy
> prefix password jak w OTPW. Dla programu łamiącego... hm... weźmy
> pięciocyfrową liczbę. Mamy ln 10/ln 2 = 3,322 bita na cyfrę, razy
> pięć to będzie 16,6 bitów na hasło. Przy siedmiu znakach
> litery/cyfry, mamy ln (26*2+10 = 62)/ln 2=5,954 bitów na znak, razy
> siedem to jest 41,68 bitów na hasło. Rzeczywiście, wciąż mało jak na
> dzisiejszą moc obliczeniową. Chociaż, jak na jednorazy w systemie
> OTPW, gdzie szansę trafienia możesz mieć jak jeden do kilkuset tysięcy
> (wspomniany wyżej system z wybieraniem iluś cyfr z długiej tabeli może
> być jakimś słabszym wariantem OTPW, co zresztą wcześniej opisałem).

Ale co przez to zyskujesz? Nic. Zabezpieczyc sie przed bankiem nie jestes
w stanie, bo to bank generuje Ci hasla i przesyla poczta. Nic nie stoi
na przeszkodzie, by zaradny specjalista robil druga kopie "na wszelki
wypadek".

> > Tak przypuszczam. Taki hash MD5 zapisany w postaci dziesietnej mialby
> > tylko ok. 128/10*3 = czterdziesci cyfr. Przy SHA1 tylko drobne 50 cyferek.
>
> A kto mi (a właściwie bankowi) zabroni wygenerować 64-, 48-, a nawet
> 32-bitowy skrót SHA1 albo MD5? Że zamiast 128 bitów entropii będą 64?
> Do jednorazów wystarczy. Powtarzam, nie widziałem rozwiązań haseł
> jednorazowych stosowanych przez banki, byłem przekonany, że nie
> stosują rozwiązań, które bym obśmiał, jakby ktoś mi sugerował
> zabezpieczenie tym konta pocztowego, a co dopiero dorobku całego
> życia... ;)

Wbrew pozorom, roznica pomiedzy stosowanymi przez banki np. 5-cyfrowymi
haslami jednorazowymi a np. 32 czy 64-bitowymi skrotami nie jest wcale
taka duza - ani jedno, ani drugie nie zabezpiecza uzytkownika przed
dzialaniem banku na jego szkode, oraz jedno i drugie dosc dobrze
zabezpiecza uzytkownika przed dzialaniem osob trzecich.
--
Krzysztof Halasa
Network Administrator

do góry

"Maciek Pasternacki" <j...@h...org.pl> wrote in message
news:87adoqr5hx.fsf@lizard.localdomain...
> "Vizvary II Istvan" <v...@p...onet.pl> writes:
>
> > 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.
>
> 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 ...


> Inna sprawa, że to jest tak czy inaczej kwestia zaufania. Ale do
> wprowadzenia w .pl porządnych podpisów cyfrowych, to się raczej nie
> zmieni...
>
> --japh

do góry

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

Pozdrawiam,
--japh

--
__ Maciek Pasternacki <m...@j...fnord.org> [ http://japhy.fnord.org/ ]
`| _ |_\ / { ...Read some Kerouac and it put me on the tracks
,|{-}|}| }\/ to burn a little brighter now... }
\/ |____/ ( Fish ) -><-

do góry

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

> > 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.
>
> Zachowa dla siebie. A bankowi przedstawi swój klucz publiczny
> (podpisany swoim kluczem prywatnym) jako Twój.

A może dlatego banki nie powinne certyfikowac kluczy klientów ?
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.
Według mnie PKI i certyfikacja kluczy ma kilka słabych punktów (wynikają one
z tak a nie inaczej przyjetych komromisów pomiedzy wygoda a bezpieczenstwem,
mozna inaczej, ja bym preferował generowanie zadania off line) ale nie jest
tak prosto oszukac jak sugerujesz.
Niebezpieczenstwo lezy zupelnie gdzie indziej.


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

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


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

Vizvary

do góry