•  

    pokaż komentarz

    Pytanie do użytkowników blika: czy te płatności w sklepie nie są dość męczące? Płatność zbliżeniowa wymaga tylko przysunięcia karty, ewentualnie wpisania pinu. Google Pay/Apple Pay jest bezpieczniejsze, a wymaga tylko przysunięcia telefonu do czytnika. Czytam, że z blikiem muszę uruchomić apkę, przepisać gdzieś 6-cyfrowy kod a później jeszcze potwierdzić to w apce.

    •  

      pokaż komentarz

      @tmux: nigdy nie płaciłem przy kasie BLIKiem. Kilka razy przede mną osoby tym płaciły. Przypominało to płatność gotówką. Szczególnie jak net nie banglał dobrze.
      BLIKa używam do płatności online i do wyciągania gotówki z bankomatu.

    •  

      pokaż komentarz

      @tmux: plus masz taki że telefon łatwiej znaleźć. Minus tak jak piszesz. Ja tam wolę NFC.

    •  

      pokaż komentarz

      @tmux: Płaciłem w Lidlu. Tak, po pierwsze trzeba mieć neta, po drugie trzeba wpisać kod z aplikacji bankowej (u mnie IKO), po trzecie potwierdzić transakcje w swojej apce i zapłacone. Ile to trwało? Tyle co płatność gotówką, ale jak ktoś nie lubi płacić gotówką lub nie ma karty zbliżeniowej (a takich osób ze względu na bezpieczeństwo jest coraz więcej) to zapłata telefonem z włączonym transferem danych jest w sam raz :) Polecam odpalić sobie aplikację przed pakowaniem zakupów, żeby ludziom czasu nie zabierać w kolejce (chyba, że jesteś prostakiem, to tego nie rób xDD).

    •  

      pokaż komentarz

      @tmux: Jeśli twój telefon nie ma NFC to jest to opcja awaryjna w przypadku nie wzięcia karty.

    •  

      pokaż komentarz

      Google Pay/Apple Pay jest bezpieczniejsze
      @tmux: A czy firma Google/Apple ma dostęp do danych o płatności, tzn. czy zna kwotę i merchanta? Jeśli tak, to o ile jeszcze Apple byłbym w stanie przełknąć (gdybym miał urządzienie tej firmy), to musiałbym się z małpą na mózg zamienić, żeby udostępniać dane Googlowi.
      A co do bezpieczeństwa - o ile Apple Pay korzysta z Secure Element (dedykowane rozwiązanie sprzętowe, przechowujące dane karty), to Google Pay to HCE - dane karty są przechowywane przez software. Zrootowany telefon z Andkiem lub jakieś RCE na poziomie roota i dane karty możesz ukraść - zupełnie jak token aplikacji mobilnej (czyli również dostęp do BLIK). Jakie to w takim razie większe bezpieczeństwo Google Pay?

    •  

      pokaż komentarz

      @shpyo: placilem blikiem w kasie samoobslugowej i to zajmuje stanowczo za duzo czasu, szczeoglnie jak w sklepie masz 1 kreske zasiegu, w tym wypadku apple pay zdecydowanie wygrywa

    •  

      pokaż komentarz

      @tmux: odpalam sobie kod jeszcze jak jest obsługiwana osoba przede mną (kod jest ważny 2 minuty). Nie mam NFC w telefonie, a moja karta nie obsługuje płatności zbliżeniowych. BLIK jest więc dla mnie najlepszą i najwygodniejszą bezgotówkową formą płatności. Czasem też płacę kartą.

    •  

      pokaż komentarz

      Zrootowany telefon z Andkiem lub jakieś RCE na poziomie roota i dane karty możesz ukraść - zupełnie jak token aplikacji mobilnej (czyli również dostęp do BLIK). Jakie to w takim razie większe bezpieczeństwo Google Pay?

      @villog: Google Pay z tego powodu odmawia pracy na zrootowanym telefonie. Co do RCE, coż, na to nie ma rady, rozwiązaniem może być jakiś niewielki limit dzienny.

    •  

      pokaż komentarz

      Google Pay z tego powodu odmawia pracy na zrootowanym telefonie

      @tmux: Z magiskiem podobno nie odmawia ( ͡° ͜ʖ ͡°)

    •  

      pokaż komentarz

      Z magiskiem podobno nie odmawia

      @villog: Potwierdzam ( ͡° ͜ʖ ͡°)

    •  

      pokaż komentarz

      @tmux: btw jak wygląda używanie apple play przy kwotach powyżej 50pln? Przy karcie trzeba wpisywac pin a w apple play też jest dodatkowe zabezpieczenie?

    •  

      pokaż komentarz

      @niko444: tutaj zabezpieczeniem jest odblokowanie telefonu

    •  

      pokaż komentarz

      to o ile jeszcze Apple byłbym w stanie przełknąć (gdybym miał urządzienie tej firmy),

      @villog: identyczny zestaw danych odnośnie transakcji dajesz i Apple i Google. Pod tym względem nie ma żadnej różnicy.

    •  

      pokaż komentarz

      Sec

      @villog: nie do końca: dane tokenu są przechowywane przez soft na telefonie (dedykowane SDK), a nie dane karty. Tokenu nie użyjesz na innym urządzeniu niż Twoje. Żeby "wyciągnąć" wszystko i włożyć do innego telefonu zajmuje przynajmniej 1,5h i wiąże się ze stały dostępem do urządzenia. Kolejna rzecz, że ilość transakcji bez połączenia do internetu (i aplikacji bankowej, do której trzeba się zalogować) jest ogarniczona. Jest to bardzo bezpieczne rozwiązanie. Brak SE jest tylko i wyłącznie wynikową fragmentacji rynku Androida. W przypadku Ap - sprawa jest jasna.

    •  

      pokaż komentarz

      @birdland

      identyczny zestaw danych odnośnie transakcji dajesz i Apple i Google. Pod tym względem nie ma żadnej różnicy.

      Zestaw danych identyczny, ale różnica taka, że Apple w przeciwieństwie do Google nie jest firmą reklamową. Apple nie ma za bardzo interesu żeby obracać moimi danymi (bo ich produkty są zwykle drogie i obłożone wysoką marżą - zarabiają wystarczająco), a Google jak najbardziej. Dla mnie to znacząca różnica.

      nie do końca: dane tokenu są przechowywane przez soft na telefonie (dedykowane SDK), a nie dane karty. Tokenu nie użyjesz na innym urządzeniu niż Twoje.

      Tak, wiem że zarówno płatności od Google jak i Apple nie operują na surowym numerze karty, tylko korzystają z tokenizacji. Ale z jakiego to niby powodu nie jestem w stanie wykorzystać tokena na innym urządzeniu (oczywiście zakładając, że mam roota)? Rozwiniesz?

      Czyżby chodziło o Trusty TEE i dostęp do keystore w enklawie? A tego też nie dało się czasem obejść?

    •  

      pokaż komentarz

      @birdland: W temacie HCE znalazłem coś takiego. A tu video z prezentacji na HITB. Niby z 2017 roku, ale kto wie czy nie jest to nadal aktualne.

      Ten fragment brzmi raczej mało optymistycznie:

      Q: But the payment keys stored on a device are of limited use, and after a few transactions have to be pushed again to the device?
      A: We have proved that the attacker is able to intercept also the payment keys refreshing – get the new keys on his cloned device, and thus make more transactions.


      I raczej przeczy Twojemu stwierdzeniu, że "zajmuje przynajmniej 1,5h i wiąże się ze stały dostępem do urządzenia". A co do tego:

      Brak SE jest tylko i wyłącznie wynikową fragmentacji rynku Androida.

      Akurat Android wg oficjalnej dokumentacji niby też obsługuje Secure Element, więc nie widzę powodu, żeby w lepiej wyposażonych (i pewnie droższych) urządzeniach, umieszczać ten chip i z niego korzystać.

      Myślę, że w świetle powyższego, stawianie znaku równości pomiędzy bezpieczeństwem rozwiązania od Apple i Google (na większości smartfonów z Andkiem) jest raczej sporym nadużyciem.

    •  

      pokaż komentarz

      @villog:
      A: We have proved that the attacker is able to intercept also the payment keys refreshing – get the new keys on his cloned device, and thus make more transactions.

      > tak, jest to teoretycznie możliwe w implementacji, kiedy SDK/Aplikacja z SDK łączy się bezpośrednio z serwerem SUK/LUK (kluczy). W przypadku implementacji przez serwery banku - bardzo utrudnione, ze względu na uwierzytelnianie użytkownika i urządzenia na podstawie aplikacji, urządzenia i kodu autoryzującego (do aplikacji).

      I raczej przeczy Twojemu stwierdzeniu, że "zajmuje przynajmniej 1,5h i wiąże się ze stały dostępem do urządzenia"

      > czas, o którym wspomniałem był dla roku 2016 (wtedy przeprowadzałem certyfikację). Widać niestety postęp...

      Akurat Android wg oficjalnej dokumentacji niby też obsługuje Secure Element, więc nie widzę powodu, żeby w lepiej wyposażonych (i pewnie droższych) urządzeniach, umieszczać ten chip i z niego korzystać

      > Google "ma w głowie" raczej standaryzację bez względu na posiadany sprzęt. Nie opiera swojego rozwiązania na hardware tylko na software. Ale fakt - rozwiązanie jest elastyczne i może bez problemu obsługiwać również SE.

      Myślę, że w świetle powyższego, stawianie znaku równości pomiędzy bezpieczeństwem rozwiązania od Apple i Google (na większości smartfonów z Andkiem) jest raczej sporym nadużyciem.

      > I tak i nie - zależy z jakiej perspektywy patrzysz. Przez ostatnie 3 lata odkąd w tym siedzę nie miałem żadnego zgłoszenia dot. fraudu na tokenie (użycie bez wiedzy użytkownika). Że nie działa - masę, ale nigdy, że ktoś go użył bez wiedzy.

      Różnica między SE a HCE jest oczywista. I nie będe się spierał na temat bezpieczeństwa jednego i drugiego - hardware to hardware, a software... jest (teoretycznie) bardziej podatny i szybszy do złamania.

    •  

      pokaż komentarz

      A: We have proved that the attacker is able to intercept also the payment keys refreshing – get the new keys on his cloned device, and thus make more transactions.

      @villog: i jeszcze: to wskazuje na podatność szyfrowania komunikacji samej aplikacji, w której siedzi SDK niż samego SDK. Ale zapoznam się szerzej z tematem bo mnie zainteresowałeś.

    •  

      pokaż komentarz

      Tak, wiem że zarówno płatności od Google jak i Apple nie operują na surowym numerze karty, tylko korzystają z tokenizacji. Ale z jakiego to niby powodu nie jestem w stanie wykorzystać tokena na innym urządzeniu (oczywiście zakładając, że mam roota)? Rozwiniesz?

      @villog: generowanie samego tokenu ma kilka zmiennych, min unikalny identyfikator urządzenia, którego mechanizm generowania jest w SDK dostawcy - wiem tylko, że min. bada kilka komponentów fizycznych urządzenia, natomiast cała reszta jest dla mnie - ze względu na spore zaciemnienie kodu i ogólną niedostępność (co nie było "standardem" jeszcze w 2016 roku) - tajemnicą.
      Sprawdzał u mnie to człowiek z firmy typu "zaufana..." o sporej renomie w środowisku - wierzę mu na słowo.

    •  

      pokaż komentarz

      generowanie samego tokenu ma kilka zmiennych, min unikalny identyfikator urządzenia, którego mechanizm generowania jest w SDK dostawcy - wiem tylko, że min. bada kilka komponentów fizycznych urządzenia, natomiast cała reszta jest dla mnie - ze względu na spore zaciemnienie kodu i ogólną niedostępność (co nie było "standardem" jeszcze w 2016 roku) - tajemnicą.

      @birdland: Heh, kiedyś właśnie z czystej ciekawości chciałem się nieco bliżej przyjrzeć takiej aplikacji jednego z banków, implementującej płatności poprzez NFC/HCE, żeby sobie zobaczyć jak to działa "pod spodem". O ile jeszcze kod smali da się jakoś przeglądać, to jak zobaczyłem, że biblioteki w kodzie natywnym mają po kilka MB, to szybko dałem sobie spokój :)

    •  

      pokaż komentarz

      @villog: Panie, w tej chwili SDK mają po ok 50MB na dostawcę. Trochę to wykastrujesz, ale nie wiele, żeby wszystko działało bez problemu. Dodaj do tego jeszcze samą aplikację banku i masz...

  •  
    s.....................e

    +17

    pokaż komentarz

    Ci z BLIKa to wygrali życie jak bilgejc albo ten typ od apla

  •  

    pokaż komentarz

    Bardzo spodobał mi się BLIK. Super wygodny do płacenia za zakupy internetowe lub wypłatę z bankomatu, ale spotkała mnie jedna nie miła niespodzianka. Miałem problem z jednym zakupem przez internet. Sprzedawca ociągał się długo z wysyłką towaru więc anulowałem zamówienie a później ociągał się ze zwrotem za transakcję, a BLIK nie ma cashbacka. Gdyby BLIK miał coś na kształt cashback byłby prawie idealny.

  •  

    pokaż komentarz

    Blik jest dobry jeśli chodzi o natychmiastowe przekazanie gotówki. Czasem będąc w innym mieście pożyczam moim starszym kasę w ten sposób, że oni idą do bankomatu, ja podaję kod blik, oni wpisują, ja potwierdzam i już.

    •  

      pokaż komentarz

      @Karysu: To jest chyba najlepsze w Bliku, a jednocześnie mało popularne. Czekam aż pojawi się kiedyś możliwość płacenia Blikiem rachunków np. za prąd czy gaz.

    •  

      pokaż komentarz

      @Karysu: Ja przeszkoliłem już swojego 12-letniego syna i przećwiczyliśmy przy bankomacie taki manewr "na wszelki wypadek". Jak będzie nagle potrzebował gdzieś na feriach, koloniach, czy z kumplami na mieście pieniędzy, to dzwoni do mnie i wypłaca blikiem. Żaden bank jeszcze nie pozwala na konto i kartę dla 12-latka.

    •  

      pokaż komentarz

      Żaden bank jeszcze nie pozwala na konto i kartę dla 12-latka.

      @olin: Oficjalnie nie, ale niektóre banki oferują albo karty wirtualne (w sam raz do przewalenia na konsoli) albo plastikowe prepaidowe, które są tak bezpieczne jak gotówka.

    •  

      pokaż komentarz

      @McRancor: ty gościu pod jakim kamieniem żyjesz? ile to już lat tego nie ma xD

    •  

      pokaż komentarz

      @McRancor: Akurat jestem mądrzejszy o doświadczenie kolegi z pracy, który tego rodzaju kartę zafundował synowi i w szkole została mu ona skradziona z plecaka w szatni na W-F... zanim zgłosił kradzież na policję, to przez internet na kocie widział gdzie było nią płacone zbliżeniowo i odwiedził Żabkę na osiedlu i monopolowy, gdzie po dogadaniu się ze sprzedawcą zobaczył film z monitoringu i na nim kolegę z klasy syna i jego starszego brata... jest sprawa, kurator, ofiara - konfident i generalnie nic dobrego z tego nie wyszło, więc może lepiej nie "prowokować wypadków" wśród małolatów.

    •  

      pokaż komentarz

      @olin: Niezłe CSI

      jest sprawa, kurator

      I bardzo dobrze - złodziejstwo tępić za wszelką cenę.

      ofiara - konfident

      Chcesz powiedzieć, że syn kolegi ma teraz nieprzyjemności w szkole? Co za patologiczne towarzystwo...

      A co do samego BLIKa, to jasne - możliwość podania kodu przez telefon to super sprawa. No i są jeszcze Czeki BLIK.

    •  

      pokaż komentarz

      Oficjalnie nie, ale

      @McRancor: to co wkleiłeś jest przecież od 13 lat

      albo plastikowe prepaidowe, które są tak bezpieczne jak gotówka.

      @McRancor: i nie są na okaziciela, tylko na podstawie umowy z bankiem

      mówisz, że "są tak bezpieczne jak gotówka", a bezpieczeństwo gotówki polega na tym, że niemożna prześledzić jej transferu oraz powiązać transakcji z konkretnymi osobami - gdzie z żadnym z tych wypadków nie mamy teraz już do czynienia po zmianach prawnych sprzed kilku lat

      i co to w ogóle miało znaczyć "oficjalnie nie, ale..."?! chcesz założyć konto na inną osobę/na słupa/na siebie i dać młodemu czy co? tylko wtedy dlaczego akurat te karty, a nie inne?!

    •  

      pokaż komentarz

      @carbyne: Oficjalnie dla 12 latka, a bezpieczność w jego rękach oznacza zgubienie karty albo jej kradzież. Dla Ciebie bezpieczeństwo gotówki oznacza brak śledzenia, dla rodzica 12 latka to akurat podnosi bezpieczeństwo rozwiązania.

      Masz strasznie pretensjonalny ton, nie mam zamiaru więcej z Tobą na ten temat dyskutować.

      @olin: Szczerze to uważam że bardzo dobrze się stało - karta prepaidowa da się ukraść tak samo jak gotówka, tyle że jak w przypadku kolegi - da się ją wyśledzić i młodych złodziei nauczyć jak to się kończy zanim realnych szkód narobią. Przecież w przypadku gdyby młody miał gotówkę tak samo by ją ukradli.

    •  

      pokaż komentarz

      Oficjalnie dla 12 latka

      @McRancor: Klikam w twój link, u góry "Pytania i odpowiedzi" i następnie pierwsze pytanie "dla kogo mogę zamówić", a tam "Jedynym warunkiem jest aby Użytkownik Karty miał skończone 13 lat". Po polsku przecież pisze.

      bezpieczność w jego rękach oznacza zgubienie karty albo jej kradzież.

      @McRancor: Nie rozumiem jak zgubienie albo kradzież ma "być bezpiecznością".

      Dla Ciebie bezpieczeństwo gotówki oznacza brak śledzenia, dla rodzica 12 latka to akurat podnosi bezpieczeństwo rozwiązania.

      @McRancor: A to zdanie to już na pewno nie ma sensu.

      Masz strasznie pretensjonalny ton

      @McRancor: Ty serio teraz? Weź trochę zmężniej może, bo cię świat zje, jak to był dla ciebie "strasznie pretensjonalny ton". Ciekawe w którym miejscu. Po prostu widzę, że mówisz nieprawdę, więc cię rozliczam, nie bierz do siebie. Jeszcze pisałeś "oficjalnie nie", a teraz już "oficjalnie dla" więc lol

  •  

    pokaż komentarz

    Jestem ogromnym zwolennikiem płatności za pośrednictwem urządzeń mobilnych. Zastanawia mnie tylko, czemu Blik nie korzysta z kodów QR, które sprzedawca mógłby skanować przy kasie. To przepisywanie kodów jest niewygodne. Ostatecznie przecież dokładnie tę samą informację można zawrzeć właśnie w postaci kodu. Taki system z powodzeniem sprawdza się choćby w Chinach, gdzie WeChat Pay i Alipay, korzystające z takiego rozwiązania, ograniczyło wyraźnie rozwój NFC.