Użytkownik "witrak()" <w...@h...com> napisał w wiadomości
news:jbnejj$3mq$1@srv.cyf-kr.edu.pl...

> Mnie szło o to, że jednak potrzeba recznej synchronizacji nie jest
> zbyt częsta, a automatyczna jest jednak nieco ryzykowna.
>
Nie widzę nic specjalnie ryzykownego w automatycznej synchronizacji.
P.G.

do góry

Użytkownik "Waldek" <m...@n...dam> napisał w wiadomości
news:jbm91h$6nr$1@node2.news.atman.pl...
>
>>> - a moze jeszcze odbiornik DCF powinien byc wbudowany
>>> i gniazdko za zewnetrzny zasilacz ? LOL
>>
>> Akurat Piotr dobrze kombinuje,
>> ale chyba nie jestes w stanie tego pojac :P
>>
> Kombinowanie mnie tu malo interesuje
> albo sie zna zasade/algorytm dzialania albo nie

Gdyby wszyscy tak myśleli to ludzkość nadal by nie umiała rozpalać ognia.
P.G.

do góry

Piotr Gałka <p...@C...pl> wrote on
2011-12-07_16:36
>
> Użytkownik "witrak()" <w...@h...com> napisał w wiadomości
> news:jbnejj$3mq$1@srv.cyf-kr.edu.pl...
>
>> Mnie szło o to, że jednak potrzeba recznej synchronizacji nie jest
>> zbyt częsta, a automatyczna jest jednak nieco ryzykowna.
>>
> Nie widzę nic specjalnie ryzykownego w automatycznej synchronizacji.
> P.G.
W granicach wąskiego przedziału (1 cykl na parę miesięcy) to
rzeczywiście nie. Ale wyobraź sobie trojana, który w twoim
komputerze opóźnia wysyłanie hasła. Przy automatycznej
synchronizacji po kilkunastu przelewach trojan ma już
zaoszczędzone całe jedno hasło, co jednak zauważyć jest dość
trudno. Wtedy czeka na wysokie saldo i wykonuje ten jeden przelew
bez możliwości zauważenia go przez użytkownika (tuż po wylogowaniu).

witrak()

do góry

Użytkownik "witrak()" <w...@h...com> napisał w wiadomości
news:jbo65h$bue$1@srv.cyf-kr.edu.pl...

>> Nie widzę nic specjalnie ryzykownego w automatycznej synchronizacji.

> W granicach wąskiego przedziału (1 cykl na parę miesięcy) to
> rzeczywiście nie. Ale wyobraź sobie trojana, który w twoim
> komputerze opóźnia wysyłanie hasła. Przy automatycznej
> synchronizacji po kilkunastu przelewach trojan ma już
> zaoszczędzone całe jedno hasło, co jednak zauważyć jest dość
> trudno. Wtedy czeka na wysokie saldo i wykonuje ten jeden przelew
> bez możliwości zauważenia go przez użytkownika (tuż po wylogowaniu).
>
Nie wiem, czy zegar służy tylko do logowania, czy też do haseł (może kiedyś
sprawdzę).
Jakby nawet też do haseł to trojan nie ma żadnego dodatkowego hasła (ilość
jest ta sama).
Po podaniu przez użytkownika ostatniego hasła trojan musi udać dla
użytkownika, że operacja się udała (wykonać jej nie może, bo potrzebuje tego
hasła dla siebie) a potem korzystając z tego hasła wykonać swoją operację.
Ale taka możliwość nie jest skutkiem automatycznej synchronizacji.
Jak zakładamy obecność trojana, to powyższe jest równoważne udaniu dla
użytkownika, że się zrobiło to co chciał i wykonaniu w tym samym czasie
swojego przelewu.
Automatyczna synchronizacja w żaden sposób nie ułatwiła według mnie zadania.
W opisie digipassa było coś, że producent dostarcza jakąś aplikację - nie
wiem, czy autoryzacje nie są w ogóle robione za pośrednictwem ich serwera.
Kwestie obsługi zegarów byłyby wtedy załatwiane przez serwer producenta.
P.G.

do góry

Użytkownik "witrak()" <w...@h...com> napisał w wiadomości
news:jbksk6$7fv$1@srv.cyf-kr.edu.pl...
> Oczywiście, jeśli zegar się rozjeżdza, to można dla konkretnej
> sztuki pamiętać przesunięcie. Ale większość się nie rozjeżdża.

Informacyjnie.
Zmierzyłem zegarek w moim digipassie. Wyszło mi, że w warunkach pokojowych
śpieszy się 0,23s/dobę.
Dokładność pomiaru szacuję na 0,05s/dobę.
Ch-ka jest taka, że zarówno ogrzanie jak i oziębienie spowoduje zwolnienie.
Jak go trochę ogrzałem (trochę mocniej niż w kieszeni) to spadł do 0s/dobę a
potem na lekki -.
Jest dokładniejszy niż myślałem, ale i tak uważam, że bez jakiegoś śledzenia
zegarów system miałby za wiele błędów.
P.G.

do góry

Piotr Gałka <p...@C...pl> wrote on
2011-12-07_19:11
>
> Użytkownik "witrak()" <w...@h...com> napisał w wiadomości
> news:jbo65h$bue$1@srv.cyf-kr.edu.pl...
>
>>> Nie widzę nic specjalnie ryzykownego w automatycznej
>>> synchronizacji.
>
>> W granicach wąskiego przedziału (1 cykl na parę miesięcy) to
>> rzeczywiście nie. Ale wyobraź sobie trojana, który w twoim
>> komputerze opóźnia wysyłanie hasła. Przy automatycznej
>> synchronizacji po kilkunastu przelewach trojan ma już
>> zaoszczędzone całe jedno hasło, co jednak zauważyć jest dość
>> trudno. Wtedy czeka na wysokie saldo i wykonuje ten jeden przelew
>> bez możliwości zauważenia go przez użytkownika (tuż po
>> wylogowaniu).
>>
> Nie wiem, czy zegar służy tylko do logowania, czy też do haseł
> (może kiedyś sprawdzę).
> Jakby nawet też do haseł to trojan nie ma żadnego dodatkowego
> hasła (ilość jest ta sama).
> Po podaniu przez użytkownika ostatniego hasła trojan musi udać dla
> użytkownika, że operacja się udała (wykonać jej nie może, bo
> potrzebuje tego hasła dla siebie) a potem korzystając z tego hasła
> wykonać swoją operację.

Nie,nie. Przeciwnie - symulując brak opóźnienia a od strony banku
spóźnianie się zegara doprowadza do sytuacji, w której klient
wprowadza *następne* hasło, mimo, że poprzednie jest jeszcze
ważne. W pewnym momencie oczywiście musi oszukać klienta, że źle
wprowadził hasło (przy logowaniu) i o od tej chwili do wylogowania
uzytkownika ma w zapasie jedno hasło, o którem user nic nie wie.

> Ale taka możliwość nie jest skutkiem automatycznej synchronizacji.

Taka jak opisałem powyżej jak najbardziej ma. Gdyby synhronizacja
nie była automatyczna, to user musiałby rozmawiać z infolinią z
chwilą osiągnięcia przez opóźnienie pełnego cyklu.

> Jak zakładamy obecność trojana, to powyższe jest równoważne udaniu
> dla użytkownika, że się zrobiło to co chciał i wykonaniu w tym
> samym czasie swojego przelewu.

To jest jednak trudniejsze, a przede wszystkim wymaga więcej pracy
- trzeba symulować całą stronę (albo właściwie kilka) - jeśli
użytkownik nie ma być od razu zaalarmowany. W opisanym przeze mnie
schemacie można sobie wyobrazić, że trojan włącza się tylko w
strumień komunikacji opóźniając wysyłanie niektórych requestów, a
swoje działanie aktywne przeprowadza tylko, gdy ma już "hasło
zapasowe w kolejce". Oczywiście, aby to było opłacalne, cracker
musiałby zainfekować wiele kompów i po jakimś czasie zezwolić im
na wykonanie fraudu 9 po czym likwidować interes.

> W opisie digipassa było coś, że producent dostarcza jakąś
> aplikację - nie wiem, czy autoryzacje nie są w ogóle robione za
> pośrednictwem ich serwera. Kwestie obsługi zegarów byłyby wtedy
> załatwiane przez serwer producenta.

Bardzo sensowne. Dla Vasco ZTCW tak było.

witrak()

do góry

Piotr Gałka <p...@C...pl> wrote on
2011-12-07_20:21
>
> Użytkownik "witrak()" <w...@h...com> napisał w wiadomości
> news:jbksk6$7fv$1@srv.cyf-kr.edu.pl...
>> Oczywiście, jeśli zegar się rozjeżdza, to można dla konkretnej
>> sztuki pamiętać przesunięcie. Ale większość się nie rozjeżdża.
>
> Informacyjnie.
> Zmierzyłem zegarek w moim digipassie. Wyszło mi, że w warunkach
> pokojowych śpieszy się 0,23s/dobę.
> Dokładność pomiaru szacuję na 0,05s/dobę.
> Ch-ka jest taka, że zarówno ogrzanie jak i oziębienie spowoduje
> zwolnienie.
> Jak go trochę ogrzałem (trochę mocniej niż w kieszeni) to spadł do
> 0s/dobę a potem na lekki -.
> Jest dokładniejszy niż myślałem, ale i tak uważam, że bez jakiegoś
> śledzenia zegarów system miałby za wiele błędów.
> P.G.

To w pewnym sensie ułatwia bezpieczną automatyczną synchronizację,
bo jeśli zegar w normalnych warunkach może się tylko śpieszyć, to
hasło może "zaginąć" z sekwencji, a dosynchronizowanie powoduje
tylko jego unieważnienie po stronie banku.
To całkowicie uniemożliwia zastosowanie schematu, który w
poprzednim poście opisałem.

pozdr.

witrak()

do góry

Użytkownik "Piotr Gałka" <p...@C...pl> napisał w
wiadomości news:4edf8c4b$1@news.home.net.pl...
>>>
>> Kombinowanie mnie tu malo interesuje
>> albo sie zna zasade/algorytm dzialania albo nie
>
> Gdyby wszyscy tak myśleli to ludzkość nadal by nie umiała rozpalać ognia.

W tym wypadku jest to wywazanie otwartych drzwi
bo urzadzenie jest i dziala w oparciu o okreslony schemat.
Kombinowanie ma sens gdy sie tworzy cos nowego.

do góry

On Wed, 07 Dec 2011 20:42:57 +0100, "witrak()" <w...@h...com>
wrote:

>ważne. W pewnym momencie oczywiście musi oszukać klienta, że źle
>wprowadził hasło (przy logowaniu) i o od tej chwili do wylogowania
>uzytkownika ma w zapasie jedno hasło, o którem user nic nie wie.

ale chyba to hasło "ma" tylko przez minutę (czy ile tam trwa "okienko"
ważności)? Potem i tak przestanie być ważne.
--
pozdrawiam,
Jarek Andrzejewski

do góry

Użytkownik "witrak()" <w...@h...com> napisał w wiadomości
news:jbodln$e6a$1@srv.cyf-kr.edu.pl...
> Nie,nie. Przeciwnie - symulując brak opóźnienia a od strony banku
> spóźnianie się zegara doprowadza do sytuacji, w której klient
> wprowadza *następne* hasło, mimo, że poprzednie jest jeszcze
> ważne. W pewnym momencie oczywiście musi oszukać klienta, że źle
> wprowadził hasło (przy logowaniu) i o od tej chwili do wylogowania
> uzytkownika ma w zapasie jedno hasło, o którem user nic nie wie.
>
Zakładasz, że user w odpowiednich odstępach robi kolejne operacje, abyś za
każdym razem mógł użyć poprzednie hasło zamiast aktualnego. Poprzez
odpowiednie opóźnienia transmisji w tę i w tę stronę nie da się aż tak
podporządkować usera (no chyba, że go nie dziwi, że strona działa jakby
chciała i nie mogła ;-)
To się ogólnie nie trzyma kupy.
P.G.

do góry