piątek, 26 marca 2021 o 13:14:30 UTC+1 Michal Jankowski napisał(a):
> W dniu 26.03.2021 o 13:09, Dawid Rutkowski pisze:
> > czwartek, 25 marca 2021 o 18:49:03 UTC+1 Kamil Jońca napisał(a):
> >> Dawid Rutkowski writes:
> >>
> >> [...]> 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ć - tym bardziej, że z
> >>> jednej stronie prymitywny kod, ale do jego wygenerowania konieczny
> >>> jest niesamowity smarkfon z android/ios (jedynie skarbonka zrobiła
> >> A do tego "kodu" nie jest potrzebny kontakt z centralą? Mogę się mylić,
> >> ale mam wrażenie, że "wygenerowanie" kodu blik na telefonie polega na
> >> tym że telefon się odpytuje centrali.[1]
> >
> > 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?
> Nie musi wszystkich, bo aktywnych kodów jest w danej chwili znacznie
> więcej niż jeden.

Ale też zwykle kod nie jest aktywny przez całe 2 minuty - zwykle tylko przez kilka
sekund mijających od żądania wygenerowania - to jest zwykle na żądanie - do
przepisania.

> Dlatego te "czeki" mają więcej cyfr.

Tylko o 3 cyfry - choć z "hasłem" to razem 7, zupełnie inna skala.
Choć trzeba by policzyć prawdopodobieństwo.
Czeki mają niestety max. okres ważności 3 doby - to też niestety zabija ich
funkcjonalność (oprócz tego zabijają głupie pomysły banków, np. skarbonki, na
blokowanie na koncie sumy odpowiadającej max. wartości wygenerowanych czeków - a do
tego skarbonka jeszcze dodaje do każdego czeku 5zł na ew. wypłatę w innym bankomacie
niż skarbonkowy lub santander) - np. nie da się mieć na zapas w kieszeni kilku czeków
do awaryjnej wypłaty w bankomacie.

do góry

piątek, 26 marca 2021 o 13:27:04 UTC+1 Kamil Jońca napisał(a):
> Dawid Rutkowski writes:
>
> > czwartek, 25 marca 2021 o 18:49:03 UTC+1 Kamil Jońca napisał(a):
> >> Dawid Rutkowski writes:
> >>
> >> [...]> 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ć - tym bardziej, że z
> >> > jednej stronie prymitywny kod, ale do jego wygenerowania konieczny
> >> > jest niesamowity smarkfon z android/ios (jedynie skarbonka zrobiła
> >> A do tego "kodu" nie jest potrzebny kontakt z centralą? Mogę się mylić,
> >> ale mam wrażenie, że "wygenerowanie" kodu blik na telefonie polega na
> >> tym że telefon się odpytuje centrali.[1]
> >
> > 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?
> >
> > 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.
>
> 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 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?).

> [...]
> > A ogólnie chodziło mi o to, że na pewno nie potrzeba do takiej
> > funkcjonalności komputera aż z androidem/ios - spokojnie starczyłyby
> > 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 czy taki kod nie mógłby np. przychodzić SMSem?
Czy trudno się podrabia numer prezentowany w banku? W citku jak dzwonię z
zarejestrowanego u nich numeru, to nie muszę podawać "loginu", tylko samo hasło.
Więc czemu nie telefon pod specjalny numer, hasło DTMFem (do apki też się musisz
zalogować) - i przychodzi SMS z kodem ważnym 2 minuty? Po co to potwierdzanie?

do góry

Dawid Rutkowski <d...@w...pl> writes:

> Można się zastanawiać nad tym, skąd ten problem z przepisywaniem kodu blik w kasie.
> I w sumie po co kod 6-cyfrowy, mógłby być 4-cyfrowy i wtedy byłoby to
> prawie to samo, co pin.

No ale to jest przecież zupełnie coś innego niż PIN. PINy wielu różnych
kart mogą być (i są) takie same. Kody BLIK, w czasie swojego istnienia,
nie mogą być takie same.
Może 10 k kodów wystarczyłoby w czasie największego ruchu. A może nie.
Poza tym, zdaje się, BLIK ma być (w ambicji twórców) ogólnoświatowy -
weźmy takie Chiny lub Indie...

> Karta jest po prostu lepsza - mimo swoich wad (bo najlepsza jest naklejka).
> A pomysł płacenia bezstykowego i bezPINowego okazał się mega
> rewelacyjny, mimo biadoleń.

Płacenie bezstykowe ma się dokładnie nijak do braku PINu - pomijając
obecne "polityczne" ustalenia. Właściwie, zwłaszcza w kontekście
starszych kart bezstykowych, bardziej do (selektywnego itp.) braku PINów
kwalifikują się karty stykowe.
--
Krzysztof Hałasa

do góry

Dawid Rutkowski <d...@w...pl> writes:

> piątek, 26 marca 2021 o 13:27:04 UTC+1 Kamil Jońca napisał(a):
>> Dawid Rutkowski writes:
>>
>> > czwartek, 25 marca 2021 o 18:49:03 UTC+1 Kamil Jońca napisał(a):
>> >> Dawid Rutkowski writes:
>> >>
>> >> [...]> 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ć - tym bardziej, że z
>> >> > jednej stronie prymitywny kod, ale do jego wygenerowania konieczny
>> >> > jest niesamowity smarkfon z android/ios (jedynie skarbonka zrobiła
>> >> A do tego "kodu" nie jest potrzebny kontakt z centralą? Mogę się mylić,
>> >> ale mam wrażenie, że "wygenerowanie" kodu blik na telefonie polega na
>> >> tym że telefon się odpytuje centrali.[1]
>> >
>> > 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?
>> >
>> > 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.
>>
>> 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 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?).

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?


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


KJ


--
http://stopstopnop.pl/stop_stopnop.pl_o_nas.html

do góry

Dawid Rutkowski <d...@w...pl> writes:

> 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 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?).

Zależy w jakich, ale jedna z opcji to coś takiego, że po każdym
skutecznym użyciu tokena w serwerze autoryzacyjnym uaktualniana jest
odpowiednia poprawka szybkości zegara (dla danego tokena). Tym sposobem
token może się rozjechać z czasem i o pół godziny, a serwerowi to nie
przeszkadza.
... do momentu, w którym ktoś chce użyć tokena po roku nieużywania,
i dodatkowo token był trzymany przez ten czas w lodówce.

> Ale czy taki kod nie mógłby np. przychodzić SMSem?
> Czy trudno się podrabia numer prezentowany w banku? W citku jak
> dzwonię z zarejestrowanego u nich numeru, to nie muszę podawać
> "loginu", tylko samo hasło.
> Więc czemu nie telefon pod specjalny numer, hasło DTMFem (do apki też
> się musisz zalogować) - i przychodzi SMS z kodem ważnym 2 minuty? Po
> co to potwierdzanie?

Takich rozwiązań raczej nie robi się dla maleńkiej grupy klientów.
--
Krzysztof Hałasa

do góry

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.

do góry

W dniu 26.03.2021 o 12:52, Dawid Rutkowski pisze:
> czwartek, 25 marca 2021 o 18:28:18 UTC+1 ToMasz napisał(a):
>>> Ale wytłumacz w takim razie, czym dla Ciebie jest "blik", żebyśmy rozmawiali na
wspólnym mianowniku ;)
>> często coś robimy, co samo w sobie nie ma sensu, ale gdy jest robione
>> przez tłum staje się mocno pozytywne. np segregacja śmieci, oszczędzanie
> [...]
>
> Echh, populiści, bujać to my, ale nie nas.
{...}
ale to przykłady
> Terminale first data - 0,65% za każdą transakcję - chyba również blik

Z terminalami jest tak, że wszystko jest negocjowalne, w zależności ile
masz obrotu i fizycznych terminali. nie mam pojęcia skąd masz te
cenniki, ale w praktyce jest tak że płacisz osobno firmie która użycza
terminala, osobno procent od każdej transakcji.
to mam na myśli mówiąc że ten procent, który otrzymuje mastercard/visa
trafia za granicę. oczywiście po odliczeniu kosztów własnych, którymi
można bardzo mocno manipulować.
Nie mam bladego pojęcia co to jest IF dla banku. ale wiem, że jeśli masz
firmę, telefon firmowy, w nim konto bankowe firmowe, to możesz
przyjmować przelew blik - telefon telefon. nie masz terminala, nie masz
opłaty 0.65% od kwoty zapłaty.
> Więc nikt aż tyle - 0,5% - nie wyprowadza, trzeba odjąć IF, które zostaje w polskim
banku (tzn. w banku
> prowadzonym przez spółkę z KRS, bo większość z kapitałem zagranicznym, więc też
pewnie wyprowadzają,
przelewy mamy darmowe, przelewy blik mamy darmowe, więc skąd konieczność
płacenia za płatność kartą? Nie wiem jak to inaczej napisać. skoro
wszyscy się zgadzają na dojenie, to są dojeni. ale alternatywa istnieje.

> A i blik darmowy nie jest, choć zgoda, że tańszy.
To co napisałem wyżej, jest mi znane z autopsji. ale ten termial który
obsługuję, nie ma możliwości przyjmowania płatności blik,, więc nie
wiem. wiem ze mogę przyjmować telefonem, tyle że jest to niewygodne, bo
(nie znam innej możliwości) potrzebne jest wpisywanie samego numeru
telefonu, czyli znowu 6 cyfr, lub trzymanie go w książce telefonicznej,
co wcale takie głupie nie jest, jeśli się robi cykliczne zakupy.
Tylko proszę nie pisz ze to głupie i kto tak robi. segregowanie smieci
20 lat temu też wydawało sie głupie, a w tym konkrentym przypadku, ja
nie udowadniam ze to jest lepsze, tylko ze istnieje możliwość żeby było
bezgotówkowe i darmowe.

> Co do dzieci płacących kodem blik usłyszanym przez telefon - czy to w sumie nie
jest to samo,
> gdyby płaciły daną im do łapy kartą rodzica? Proszenie się o kłopoty.
nie. chyba nie zrozumiałeś. Dziecko moze znaleźć się w trudniej
sytuacji, bez pieniędzy z potrzebą zrobienia jakichś nagłych zakupów.
Może poprosić o pomoc kolegę, który nie ma kasy, ale ma telefon.
zadzwonić do mamy - potrzebuję 20zł na jedzenie i picie bo coś mi
wyskoczyło, czy możesz mi "zapłacić zdalnie" - oczywiście. na swoim
telefonie widzę kwotę, więc nie ma tu mowy o nadużyciu.

> Można się zastanawiać nad tym, skąd ten problem z przepisywaniem kodu blik w kasie.
> I w sumie po co kod 6-cyfrowy, mógłby być 4-cyfrowy i wtedy byłoby to prawie to
samo, co pin.
> Prawie - bo trzeba niestety jeszcze wyciągnąć słuchawkę, a do tego brakuje trzeciej
albo i czwartej ręki.
co? nie przesadzasz? W "dzieckowym" przykładzie żadne z nich nie
wyjmuje telefonu bo mają słuchawki. karta plus pin, to też w zasadzie 2
ręce.

> Karta jest po prostu lepsza - mimo swoich wad (bo najlepsza jest naklejka).
> A pomysł płacenia bezstykowego i bezPINowego okazał się mega rewelacyjny, mimo
biadoleń.
moment moment. płacenie przez przyłożenie jakiegoś urządzenia do
czytnika - genialne i wygodne. 100% zgody. Ale od pewnego czasu,
chętniej nosimy smartfona, niz portfel zegarek i tip. Więc wbudowanie
płatności w telefon jest rozwinięciem genialnego pomysłu. zgoda? Czy
można w tym coś spieprzyć? Oczywiście. aby zapłacić telefonem musisz
podać pin, kod itp. odblokowywanie twarzą w masekczkach nie działa.
odblokowuywanie odciskiem palca - różnie, w różnych telefonach. zależy
to od telefonu i palców. i tu przyznaję Ci racje. naklejka lub karta
wbudowana w etui telefonu, nie potrzebuje odblokowania, telefon
realizujący tą samą funkcję - już tak. Zdaję sobie sprawę że tak czy
siak 95% ludzi ma jakis pin, kod do telefonu, ale ja do ciężkiej
cholery nie chcę. Mogę pinować nawet 16 znaków, ale jak stoję w kolejce
w markecie, a odblokowywać te same zabezpieczenia do płacenia i
telefonowania. bez sensu.

> I za to właśnie blik bedzie musiał odpalić działkę mastercardowi - bo to mc
wymyślił pikacz,
> visa też buli.
o tym nie mam pojęcia, ale cieszyłbym się niezmiernie, gdyby blik
działał szybciej i wygodniej w przelewach telefon-telefon -
masercard/visa dostaliby w dupę
chciałbyś policzyć jaka byłaby to kwota?

ToMasz

do góry