Użytkownik "Robert" <s...@o...pl> napisał w wiadomości
news:aspri2$dg2$1@topaz.icpnet.pl...
> In news:aspqn4$h07$1@korweta.task.gda.pl, allman wrote:
>
> Ja mam od ponad 2 lat i jestem zadowolony. Problemy z logowaniem (token)
> zdarzają się sporadycznie,
U mnie ostatnio jest to nagminne, chociaz jeszcze nie zablokowalem sobie
konta. :-) Jesli na tokenie jest "łatwy" do zapamietania ciag cyfr (np:
224488, lub333445 itd), to nawet nie probuje go "wklepywac" w klucz. System
praktycznie zawsze odpowiada, ze klucz jest niepoprawny. Z ciagiem cyfr, w
ktorych latwiej sie pomylic, np. 549617, taki problem jest rzadkoscia. O
dziwo w systemie transakcyjnym nigdy nie mialem problemow z akceptacja
klucza, obojetnie czy ciag cyfr to 333344, czy 967346.

>eksperymentalnie stwierdziłem, że najczęściej
> ponowna próba logowania z *kolejnym* wskazaniem tokena problem rozwiązuje.
W moim przypadku, jesli tylko ciag cyfr jest "trudny" do zapamietania,
sytuacja jest analogiczna.

> Podejrzewam, że w ten sposób system dokonuje cichej synchronizacji.
Mam to samo odczucie.

> Jak prowadzą jakieś prace to nawet 3 nieudane logowania pod rząd nie
> powodowały zablokowania kanału.
Rowniez potwierdzam.

Pozdr,
Waldek

do góry

In news:assglt$2l9$1@flis.man.torun.pl, bwwald wrote:
> Użytkownik "Robert" <s...@o...pl> napisał w wiadomości
> news:aspri2$dg2$1@topaz.icpnet.pl...
> > In news:aspqn4$h07$1@korweta.task.gda.pl, allman wrote:
> >
> > Ja mam od ponad 2 lat i jestem zadowolony. Problemy z logowaniem
> > (token) zdarzają się sporadycznie,
> U mnie ostatnio jest to nagminne, chociaz jeszcze nie zablokowalem
> sobie konta. :-) Jesli na tokenie jest "łatwy" do zapamietania ciag
> cyfr (np: 224488, lub333445 itd), to nawet nie probuje go "wklepywac"
> w klucz. System praktycznie zawsze odpowiada, ze klucz jest
> niepoprawny. Z ciagiem cyfr, w ktorych latwiej sie pomylic, np.
> 549617, taki problem jest rzadkoscia.

Podejrzewasz istnienie jakiegoś filtru wstępnego w algorytmie, który odrzuca
zbyt regularne sekwencje?
Ciekawa teza, od teraz zwrócę uwagę.
Przyznam, że odnoszę się do niej sceptycznie:

> O dziwo w systemie
> transakcyjnym nigdy nie mialem problemow z akceptacja klucza,
> obojetnie czy ciag cyfr to 333344, czy 967346.

To mogłoby oznaczać jedną z dwóch rzeczy:

1. o ile faktycznie istnieje coś takiego, co sugerujesz wyżej - to cudo
działa tylko przy logowaniu
2. podwójny token przy logowaniu służy synchronizacji; ponieważ ona już
nastąpiła przy logowaniu, nie pojawia się przy akceptacji transakcji (upływ
czasu od logowania do tej jest u mnie i pewnie u Ciebie pomijalnie niewielki
:) )

> > Podejrzewam, że w ten sposób system dokonuje cichej synchronizacji.
> Mam to samo odczucie.

No czekaj, bo się tu pogubiłem - wydawało mi się, że sugerujesz tę skłonność
do odrzucania regularnych liczb jako alternatywę do wytłumaczenia
synchronizacji?
Zatem powiadasz, że obie te przyczyny zachodzą?

Z ostatniej chwili: w czasie pisania tego posta zalogowałem się dwukrotnie
pierwszą próbą takimi wskazaniami tokena:
787875
600165
Nie wiem, czy są one wystarczająco "regularne", ale rozumiem, że jesli choc
raz uda mi się zalogować z bardzo łatwym numerkiem za pierwszym razem, to
tezę uznasz za obaloną?
Zapraszam Lukas Tokenowców do testów :)


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

do góry

In news:asshv1$uc5$1@topaz.icpnet.pl, Robert wrote:

> Z ostatniej chwili: w czasie pisania tego posta zalogowałem się
> dwukrotnie pierwszą próbą takimi wskazaniami tokena:
> 787875
> 600165
> Nie wiem, czy są one wystarczająco "regularne", ale rozumiem, że
> jesli choc raz uda mi się zalogować z bardzo łatwym numerkiem za
> pierwszym razem, to tezę uznasz za obaloną?
> Zapraszam Lukas Tokenowców do testów :)

Pierwszy korzystam z zaproszenia. Następujące wskazania tokena dały wynik
sukces w pierwszej próbie (od czasu ostatniego posta):

183444
036090
633555

Człowiek ma dużą skłonność do strukturyzowania percepcji: widzenia
regularności, gdzie faktycznie jej nie ma...

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

do góry

Użytkownik "Robert" <s...@o...pl> napisał w wiadomości
news:asshv1$uc5$1@topaz.icpnet.pl...
> In news:assglt$2l9$1@flis.man.torun.pl, bwwald wrote:
> > Użytkownik "Robert" <s...@o...pl> napisał w wiadomości
> > news:aspri2$dg2$1@topaz.icpnet.pl...
> > > In news:aspqn4$h07$1@korweta.task.gda.pl, allman wrote:
> Podejrzewasz istnienie jakiegoś filtru wstępnego w algorytmie, który
odrzuca
> zbyt regularne sekwencje?

Podejrzewam, ze synchronizacja nastepuje dla latwych do zapamietania
cyfrach. Te jest szybciej zapamietac i system synchronizujacy "wie", ze na
tokenie przewaznie jest jeszcze duzo kresek, wowczas latwiej zsynchronizowac
token. 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.

> > O dziwo w systemie
> > transakcyjnym nigdy nie mialem problemow z akceptacja klucza,
> > obojetnie czy ciag cyfr to 333344, czy 967346.
>
> To mogłoby oznaczać jedną z dwóch rzeczy:
>
> 1. o ile faktycznie istnieje coś takiego, co sugerujesz wyżej - to cudo
> działa tylko przy logowaniu

Dziala rowniez wtedy, gdy dlugo bezskutecznie (kilka razy) odswiezam stan
konta, chociaz nie przekroczyłem stanu bezczynności, powodujacego utracenie
lacznosci z serwerem. Wowczas rowniez musze ponownie wpisywac klucz aby sie
"re-logowac".

> 2. podwójny token przy logowaniu służy synchronizacji; ponieważ ona już
> nastąpiła przy logowaniu, nie pojawia się przy akceptacji transakcji
(upływ
> czasu od logowania do tej jest u mnie i pewnie u Ciebie pomijalnie
niewielki
> :) )
Ale już przy odswiezaniu stanu konta był nawet godzinny i sytuacja sie
powtarza.
(w czasie długiego odswiezania wykonuje inne czynnosci aby pozostac w
systemie)

> Z ostatniej chwili: w czasie pisania tego posta zalogowałem się dwukrotnie
> pierwszą próbą takimi wskazaniami tokena:
> 787875
> 600165
A logowales sie dzisiaj wczesniej?

> Nie wiem, czy są one wystarczająco "regularne", ale rozumiem, że jesli
choc
> raz uda mi się zalogować z bardzo łatwym numerkiem za pierwszym razem, to
> tezę uznasz za obaloną?
Nie, bo nie jest to regularnosc, zalezy to czasu od ostatniego logowania.
Poza tym kazda regula ma wyjatki ;-). W moim przypadku jest to "jedynie"
zbyt czeste. Zawsze bowiem przy logowaniu bez wzgledu na latwy, czy
trudniejszy ciag cyfr, wpisuje je w tym samym czasie wskazan tokena. Nie ma
wiec mowy o zmiennych warunkach z mojej 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.

do góry

Użytkownik "Robert" <s...@o...pl> napisał w wiadomości
news:assjla$v8u$1@topaz.icpnet.pl...
> In news:asshv1$uc5$1@topaz.icpnet.pl, Robert wrote:
> Pierwszy korzystam z zaproszenia. Następujące wskazania tokena dały wynik
> sukces w pierwszej próbie (od czasu ostatniego posta):
> 183444
> 036090
> 633555

Moze Robercie masz stary, dobry, wysynchronizowany token? ;-) Moj nie ma
jeszcze 3 miesiecy. Wiem, ze moze moje spostrzezenie to spiskowa teoria
dziejow, ale algorytm synchronizacji nie musi dzialac caly czas. W kazdym
razie, rzeczywiscie moze tak byc, jak sugerujesz, ze jesli czlowiek cos
sobie wmowi (falsz), to po pewnym czasie jest gotow w to uwierzyc :-)

Waldek

do góry

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

do góry

In news:assl3v$7qp$1@flis.man.torun.pl, bwwald wrote:

> Moze Robercie masz stary, dobry, wysynchronizowany token? ;-) Moj
> nie ma jeszcze 3 miesiecy.
Mam stary, dogorywający, rozstrojony token :))
Jakies 2 lata go mam.

> Wiem, ze moze moje spostrzezenie to
> spiskowa teoria dziejow, ale algorytm synchronizacji nie musi dzialac
> caly czas. W kazdym razie, rzeczywiscie moze tak byc, jak sugerujesz,
> ze jesli czlowiek cos sobie wmowi (falsz), to po pewnym czasie jest
> gotow w to uwierzyc :-)

Nie ocenialbym tego w tak negatywnych kategoriach.
Umysl ludzki ma niebywała zdolnosc ekstrahowania regularnosci, ulatwien,
ktore oszczedzaja ograniczone zasoby neurologiczne.
Byc moze jest tak, ze Ty, będac osobą wnikliwą, po zaskakujaco nieudanym
logowaniu (jestes prawie pewien, ze dobrze wpisales), stawiasz szereg
szybkich hipotez (niekoniecznie calkiem swiadomie). Jedna z nich jest "moze
za łatwa liczba"?
Spojrzales na token, wykryles _jakąś_ regularność i uzyskałeś potwierdzenie,
ze jest latwa... Popatrz sobie tak przez parę minut na wskazania tokena -
czy co najmniej 50% ze wskazań nie daje wrażenia przyjemnej
nieprzypadkowości? Jeśli tak, to mogłeś - utrzymując tę hipotezę - zyskiwać
dane potwierdzające w dużej części nieudanych logowań. Były też dane
zaprzeczające, ale tych się tak dobrze nie zapamiętuje, bowiem
zapamiętywanie zależy m.in. od afektu - dane potwierdzające były przyjemne,
bowiem karmiły Twoje ego potwierdzając Twoją hipotezę. Znasz pojęcie
"experimenter bias", prawda?

No, rozgadałem się ... :)


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

do góry

Użytkownik "Robert" <s...@o...pl> napisał w wiadomości
news:assm2p$10j$1@topaz.icpnet.pl...
> Łatwych liczb w każdym razie nie odrzuca na pewno, bo wlasnie zalogowalem
> sie sekwencją 000888 (chyba zacznę grać w Totka :)) )
U mnie dzisiaj tez bezproblemowo przyjmuje kazdy ciag cyfr (kilkanaście
prob) :-)

> Dlatego nie przekonuje mnie, ze wpisywanie "latwego" numeru jest jakos
> znaczaco szybsze
Znaczaco nie (chyba, ze kilka sekund to znaczacy czas), ale jest szybsze w
wielu przypadkach. Dla kogos kto nie przeszedł kursu maszynistek łatwiej
jest wpisac 111222 niż 195203.
.
>, a tym bardziej ze to przyspieszenie jest kosztem
> "szybszego zapamietywania" - jak piszesz.
W moim przypadku tak własnie jest. Ja zapamietuje wskazanie tokena podobnie
jak numer telefonu i przy tym jestem wzrokowcem, jak wiekszosc osobnikow
plci brzydkiej. Sekwencja 2 lub 3 cyfrowa. Upraszczajac, przy trudnej
sekwencji musze ja powtorzyc 1 raz, przy latwej nie musze powtarzac.

> > 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ść.
I o to właśnie chodzi. Nietypowy ciag cyfr niektorzy zapamietaja i wpisza
szybciej (tak jak łatwy ciag), niektorzy wolniej. Przy łatwym ciagu cyfr
czas zapamietywania i "wklepania" jego bedzie bardziej zblizony do siebie
dla wiekszej ilosci populacji.

> 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ł).
No i moze o to chodzi, aby czas od wskazania tokena do wykonania operacji
mial najmniejsze odchylenie standardowe, co IMHO wystepuje dla cyfr
"łatwych" lub tylko "trudnych", a nie "łatwych+trudnych".

> Wiesz oczywiście, że możesz się wylogować, a odświezanie następuje sobie
na
> serwerze?
Tak, ale ja nie chce się powtornie logowac, szczegolnie kiedy mam z nim
problemy.

> 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).
I przewaznie wowczas, gdy na tokenie mam ciag cyfr typu 223344, a nie
758451? Zobacz ponizej.

> Ja kiedys mialem faktycznie takie zjawisko i bylo wytlumaczenie...
Ja zawsze mam wpisana pierwsza czesc klucza. Po zmianie wskazan tokena
wpisuje cyfry z gornej czesci klawiatury. _Zawsze_ wysylam wskazanie klucza
_po zniknieciu pierwszej kreski_, bez wzgledu na trudnosc zapamietania cyfr
(10 sekund wystarcza). Praktycznie tylko przy latwych cyfrach wystepuje blad
kucza (klawiatura sie nie zacina ;-)) i tylko przy logowaniu.

PS.
Chyba zakonczymy, bo modemowcy nas zjedza :-)
Odpowiadajac jednoczesnie na nastepna wiadomosc: moglo tak byc, przyznam,
ale nie mam na to wystarczajacych dowodow. Parafrazując, jest tak jak
mowisz, ale ja mam troche przeciwne zdanie :-)

do góry

In news:asspt9$d8j$1@flis.man.torun.pl, bwwald wrote:

> I o to właśnie chodzi. Nietypowy ciag cyfr niektorzy zapamietaja i
> wpisza szybciej (tak jak łatwy ciag), niektorzy wolniej. Przy łatwym
> ciagu cyfr czas zapamietywania i "wklepania" jego bedzie bardziej
> zblizony do siebie dla wiekszej ilosci populacji.

Różnice między osobami nie powinny mieć znaczenia, poniewaz dane są
oddzielne dla każdego tokena.

> No i moze o to chodzi, aby czas od wskazania tokena do wykonania
> operacji mial najmniejsze odchylenie standardowe, co IMHO wystepuje
> dla cyfr "łatwych" lub tylko "trudnych", a nie "łatwych+trudnych".

Nie moge sie oprzec wrazeniu, ze zapominasz o tym, ze porownanie wskazan
nastepuje zawsze, glownie dla celow weryfikacji. Gdyby synchronizacja byla
jedynym celem w ogole (a nie weryfikacja), to powyzsze byloby prawdziwe.
Glownym celem jest jednakze weryfikacja, ktora jest dokonywana na populacji
wpisow wszelkiem maści (trudnych, łatwych, mieszanych). Synchronizacja to
wzorcowanie narzędzia. Przy wzorcowaniu korzystniej jest zebrać informację
na temat wartości typowych, nie ekstremalnych. A jeśli system byłby na tyle
skomplikowany, że oprócz miary tendencji centralnej dopasowywałby też
osobniczo parametry rozrzutu, to musiałby zbierać informacje o łatwych i
trudnych w tym samym stopniu.

> Chyba zakonczymy, bo modemowcy nas zjedza :-)
Juz teraz możemy ;)

> Odpowiadajac jednoczesnie na nastepna wiadomosc: moglo tak byc,
> przyznam, ale nie mam na to wystarczajacych dowodow. Parafrazując,
> jest tak jak mowisz, ale ja mam troche przeciwne zdanie :-)

Przyczynę tego przeciwnego zdania wskazałem w tym poscie, ktorego nie
cytujesz ;P

(tym razem wolowina :)) )

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

do góry

Użytkownik "Gall" <s...@o...pl> napisał w wiadomości
news:asqc7v$27t$1@foka.acn.pl...
> Człowieku zastanów się co piszesz! W tabeli opłat i prowizji jest jak byk
> napisane "średnie miesięczne saldo" a nie "średnie saldo w danym
miesiącu".
> No chyba że miesiąc u Lukasa liczy sobie 2 dni, bo konto założyłem 28
> listopada i do grudnia nie zdołałem przelać na nie żadnych pieniędzy. Mogę
> cię zapewnić że tego rodzaju tłumaczenie jest nie do obrony przed
> jakimkolwiek sądem. Tylko kto by się sądził o 7 zł.

a czy to nie jest tak, ze:
1) prowizja 7 zl wywolala u Ciebie nielegalny debet,
2) skasowali kolejna prowizje w wysokosci 30 zl za nielegalny debet,
3) wyslali Info do BIKu
4) przekazali pismo windykatorowi i skasowali kolejne 50 zl za wyjazd
windykatora...

Grzegorz

do góry