In news:assk3k$6tt$1@flis.man.torun.pl, bwwald wrote:

> Podejrzewam, ze synchronizacja nastepuje dla latwych do zapamietania
> cyfrach.

Chyba zle Cie zatem wczesniej zrozumialem.
Zatem nie przypuszczales, ze system *generalnie* odrzuca "latwe" liczby,
tylko preferencyjnie wybiera je do synchronizacji, tak?

Łatwych liczb w każdym razie nie odrzuca na pewno, bo wlasnie zalogowalem
sie sekwencją 000888 (chyba zacznę grać w Totka :)) )

> Te jest szybciej zapamietac i system synchronizujacy "wie",
> ze na tokenie przewaznie jest jeszcze duzo kresek, wowczas latwiej
> zsynchronizowac token.

Byc moze ktos tak to wymyslil, ale nie jest to zbyt przekonujace. Po
pierwsze, mam watpliwosci, czy wpisanie liczby wiaze sie z wczesniejszym jej
zapamietaniem. Ja przepisuje po jednej cyfrze patrzac na token. Byc moze to
ja jestem nietypowy, niemniej warto zauwazyc, ze 6 cyfr to juz jest na
granicy pojemnosci typowej short-term memory, zatem byloby to utrudnienie.
Dlatego nie przekonuje mnie, ze wpisywanie "latwego" numeru jest jakos
znaczaco szybsze, a tym bardziej ze to przyspieszenie jest kosztem
"szybszego zapamietywania" - jak piszesz.

> Rzczej wiekszosc zaczyna wpisywac klucz z
> chwila zmiany wskazania tokena, a rzadko z chwila, gdy na tokenie
> pozostala 1-2 "kreseczki", bo nie ma sie pewnosci jak dlugo bedzie
> wedrowal pakiet.

Jestem sklonny sie zgodzic, ze jest takie myslenie, choć oczywiście nie ma
to praktycznego znaczenia, bowiem występuje synchronizacja.
Najkorzystniejszym zachowaniem (o ile zegar dobrze chodzi) jest
konsekwentność.

Co do zalet szybkiego wpisywania dla dokładności synchronizacji, to przecież
zegar może się spieszyć i spóźniać, a "nietypowo szybkie" wpisanie tak samo
nie umożliwia dobrej synchronizacji jak nietypowo wolne. Przecież
synchronizacja i sama weryfikacja nigdy nie następuje bezpośrednio z
tokenem, a jedynie jego odpowiednio opóźnionym śladem (odczekanie, odczyt,
wklepanie, przesył). Zatem wybieranie ekstremalnych wartości jako wzorcowych
jest delikatnie mówiąc nieuzasadnione - zgodzisz się?

> (w czasie długiego odswiezania wykonuje inne czynnosci aby pozostac w
> systemie)
Wiesz oczywiście, że możesz się wylogować, a odświezanie następuje sobie na
serwerze?

> A logowales sie dzisiaj wczesniej?
Tak. Testowałem tezę, której chyba nie postawiłeś, tylko ja tak zrozumiałem,
patrz wyjaśnienie u góry.

> strony. I na koniec bardzo dla mnie zastanawiajace: dlaczego od ponad
> roku nie popelnilem bledu przy logowaniach do bankow bez tokena, a tu
> jest to takie czeste? Nie mozna przeciez tak czesto popelniac bledow
> przy wpisywaniu ciagu 6 cyfr (haslo wklepuje z zamknietymi oczami),
> szczegolnie gdy sa one latwe do zapamietania.

Dlaczego przypuszczasz, że popelniasz błąd (tak często)? Moim zdaniem system
celowo pyta w celu synchronizacji. Ale uzależniałbym to nie od łatwości
liczb, ale raczej od tego, że system widzi, że wpisałeś jego kod sąsiedni (w
czasie).

Ja kiedys mialem faktycznie takie zjawisko i bylo wytlumaczenie.
Wiekszosc innych hasel skladala sie gl. z liter i kilku cyfr, ktore
wpisywalem z klawiatury glownej.
Haslo Lukasa wpisuj z klawiatury glownej, potem biore do lewej reki Token, a
prawa umieszczam na klaw. numerycznej.
Problem polegal na tym, ze NumLock byl czasami wylaczony (sporadyczny bład
przy budzeniu z hibernacji - nie odzyskiwal statusu NumLock sprzed
uspienia).

W tej sytuacji faktycznie klucz do Lukasa byl czesto bledny, znacznie
czesciej niz do innych bankow :)

--
Robert
To reply by email, use ->mkarta<- in place of ->spamtrap<-
Emaile adresuj do ->mkarta<- zamiast do ->spamtrap<-