Użytkownik "Kamil Jońca" napisał w wiadomości grup
dyskusyjnych:8...@a...kjonca...
Dawid Rutkowski <d...@w...pl> writes:
> piątek, 26 marca 2021 o 13:27:04 UTC+1 Kamil Jońca napisał(a):
[...]

Nie bardzo juz lapie o co sie klocicie, ale

>> >> [...]> A ten "bezstykowy blik" to po prostu kolejny krok w
>> >> technologii.
>> >> > Ja do dziś jestem pod wrażeniem, jak taki prymitywny system z
>> >> > przepisywaniem kodów mógł się spopularyzować
[...]
>> > To "generowanie" to było ironicznie - oczywiście że kod jest
>> > pobierany z centrali.
>> > Zastanawia mnie też, po co jest to durne potwierdzanie operacji
>> > na telefonie - bali się, że ktoś w ciągu dwóch minut przeleci na
>> > jakimś terminalu wszystkie możliwe 6-cyfrowe kody?

A czemu wszystkie? Losowy poda - moze akurat trafi w jakis aktywny i
kupi na cudzy rachunek.
A jak nie trafi ... podyktuje jeszcze raz, ciut inny.
Jak i ten nie zadziala ... "to ja wygeneruje jeszcze raz".
Jak i tym razem nie trafi ... to wyciagnie gotowke i zaplaci, albo
powie "szkoda" i wyjdzie bez towaru.

A poza tym kasjer moze sie pomylic, czy zlosliwie wbije zero wiecej
... i lepiej, jak klient widzi co potwierdza.

>>> > Z drugiej strony jest przykład dawnych tokenów - tam ZTCP kod
>>> > też miał 6 cyfr i zmieniał się co 2 minuty.
>>> Ale "kontekst" był określony. (np. strona logowania banku), i
>>> tylko
>>> trzeba było sprawdzić czy kod pasuje.

Dokladnie. A przy bliku mamy tylko kod.

>>> Tu z losowego sklepu internetowego przychodzi ci kod i musisz
>>> zdecydować
>>> "do kogo należy" i u kogo potwierdzić.
>
>> Hmm, przy 6-cyfrowym kodzie mamy pewność, że gdzieś na dwóch
>> tokenach będzie to samo wskazanie dopiero przy milionie tokenów. A
>> to dopiero wskazanie - jeszcze ta dwójka musi chcieć na raz płacić.
>Ale tu nie chodzi "pewność że są 2 takie same", tylko o "pewnosć, że
>nie
ma 2 takich samych"

Ale mowa o bliku czy innych tokenach ?

W bliku duplikatow nie bedzie, bo centrala nie wygeneruje drugiego
takiego samego w czasie obowiazywania pierwszego.

A jak bedzie token bez lacznosci ... to skad wiadomo, czy klient chce
placic, czy nie chce ?

>> Ale przecież taka kolizja jest do wykrycia - centrala przecież wie,
>> jakie jest wskazanie danego tokena (to mnie zawsze zadziwiało, jak
>> precyzyjne są te zegary w tokenach - jak oni to zrobili?).

bank mogl zapamietac "ustawienie zegara tokena" od ostatniego kodu.
Tzn jest np 12:35, klient podaje kod, ktory powinien byc z godziny
12:33, bank to akceptuje, i sobie zapamietuje "klientowi sie zegar
spoznia 2 minuty".
Nastepnym razem doliczy i uwzgledni korekte przy sprawdzaniu.
W razie watpliwosci mozna poprosic o nowy kod ... i ustalic roznice
czasu dokladniej.

>Centrala wie,że na 2 urządzeniach jest to samo (tak wyszło).
>Ze sklepu przychodzi "kod:123456, kwota:17,0 PLN"
>do którego z tych 2 urządzeń ma wysłać prośbę o potwierdzenie?

No wlasnie - w Bliku kod musi byc unikalny ... w danym czasie.
Token nie zadziala.

>>> > też starsze słuchawki z J2ME. Ale to pewnie mój skrzywiony
>>> > pogląd
>>> I kontakt z centralą.
>
>> Nawet jak się przy tym uprzemy i nawet jak mus być "internetowy" to
>> J2ME jak najbardziej na to pozwalała, nawet jeśli sama transmisja
>> szła
>> przez biedniutki GPRS 2G, a ostatecznie nawet CSD (taki WAP
>> potrafił
>> transmitować nawet SMSami ;)
>Ale ja nie twierdzę, że J2ME na to nie pozwala.
>Twierdzę, że przypadek blika jest inny niż przypadek tokena
>eurobanku.

Dokladnie.

A J2ME ... czy kiedys nie uzywano w takim celu ?
A teraz juz nie, co sie dziwic - schylkowe technologie banku nie
interesuja, a zreszta nie wiadomo na ile to by bezpieczne bylo.

J.