witrak()

W oryginalnej wiadomości napisano: "Pozwoli to kilkukrotnie zmniejszyć ilość marnowanego miejsca, a jednocześnie zapisać w sektorze dwa razy więcej informacji potrzebnych do korekcji błędów." witrak() -- "Lepiej milczeć i wyglądać na głupca niż odezwać się i rozwiać wszelkie wątpliwości"

Tiaaa, jeszcze niecałe 250 lat temu człowiek nie był przypisany do określonego państwa - jeśli chciał, zmieniał miejsce zamieszkania i "nikomu nic do tego". Dzisiaj tak nie jest i po prostu nikt już nie wie, jakie to było uczucie, móc zamieszkać gdzie indziej - bez "zielonych kart", rezygnacji/starania się o obywatelstwa, itd. Ale ktoś w tych czasach mogł podobnie powiedzieć: "A niech sobie robią granice, stawiają pograniczników jeśli chcą. Nie chcą mieć swobody - to ich wybór". witrak()

To nie tak działa. To prawda, że token sprzętowy jest de facto zegarkiem, podającym czas (w minutach, od umownej dla danej serii tokenów chwili początkowej) w postaci zaszyfrowanej - innym kluczem dla każdego użytkownika (a zarazem tokenu), co powoduje, że sekwencja tych samych liczb (000000 do 999999) jest inna dla każdego tokenu. ALE: Każdy kod generowany przez token jest jednorazowy - nawet jeśli ktoś zdąży wprowadzić drugą operację przed wygaśnięciem ważności kodu to potwierdzenie jej "zużytym kodem" się nie uda. To oczywiście limituje ilość operacji bankowych - w godzinę można zrobić max 60 przelewów, jeśli zmiana kodu jest co minutę, a każdy przelew trzeba oddzielnie zatwierdzić. I tak, i nie. Bo taki token może wykorzystywać nie tylko o zmienną czasową, ale też hasło. Wtedy token ma dwa: jedno do jego odblokowania ("zalogowanie do tokenu") i drugie, potrzebne do wygenerowania kodu odpowiedzi z wprowadzonego kodu dostarczonego przez bank. W dodatku, ponieważ wygenerowany kod ma ograniczony okres ważności, przestępca nawet znając algorytm stosowany przez bank do generowanie challenge'u ma znikome szanse zdążyć tak dobrać treść "fałszywego" przelewu, aby uzyskać to samo, co bank wygenerował dla przelewu klienta (musi to robić metodą prób i błędów, bo challenge jest tworzony przez szyfrowanie). (Gdyby zdążył, mógłby unieważnić przelew oryginalny i złożyć swój, blokując na chwilę komunikację klienta, a ten wprowadzając kod do swojego przelewu potwierdziłby "fałszywkę".) Niestety już nie tylko - złamano algorytmy szyfrowania komunikacji w sieciach GSM i teraz ani rozmowy ani SMSy nie są tajne :-( Ktoś dysponujący odpowiednim sprzętem może nie tylko podsłuchać jedno i drugie, ale nawet "podstawić" fałszywą stację bazową i włączyć się w komunikację... To są skutki wiary, że tajne algorytmy są lepsze niż OpenSource, choć te drugie sprawdza więcej ludzi i dziury są wykrywane o niebo szybciej. witrak()