W dniu 2019-08-20 o 16:30, J.F. pisze:
>> Tak, masz rację. Jednocześnie Alior na swoich stronach podaje:
>> "Urządzenie z którego korzystasz do obsługi aplikacji Google Pay
>> (wczesniej Android Pay) musi być skutecznie zabezpieczone przed
>> zagrożeniami poprzez zainstalowanie aktualnego oprogramowania
>> antywirusowego renomowanego producenta."
>
>> Ciekawe czy ten wymóg może potem skutkować jakimiś problemami dla
>> klienta (np. z odrzuceniem reklamacji).
>
> Nieznane sa wyroki sadow rejonowych :-)

Jeśli jednak MUSI to wydaje się, iż bank stawia to za warunek. Z drugiej
strony są osoby, które twierdzą, że wirusów na Androida nie jest dużo.

> Z jednej strony - oczywiscie moze, z drugiej ... a gdzie lista
> renomowanych (dla banku) producentow ?

No widzisz... Dziwnie.

Przeglądałem sobie stronę dot. KK w Aliorze i tam czytam:
Zasada zerowej odpowiedzialności (Mastercard Zero Liability) chroni
posiadaczy kart przed odpowiedzialnością za nieautoryzowane transakcje
na kartach kredytowych oraz debetowych Mastercard. Zasada zerowej
odpowiedzialności to zapewnienie posiadacza karty, że jeśli
przeprowadzona zostanie jakakolwiek nieautoryzowana transakcja na karcie
Mastercard, posiadacz karty nie będzie ponosił odpowiedzialności za tę
transakcję, o ile zachowa należytą ostrożność w zabezpieczeniu karty
kredytowej oraz karty debetowej przed nieautoryzowanym użyciem i
bezzwłocznie zgłosi jej nieuprawnione wykorzystanie.

Jak widać ta "należyta ostrożność" jest kluczowa.

>> Swoją drogą do obsługi foreksu często są dostępne aplikacje mobilne i
>> na komputery. Banki rozwijają te pierwsze, ale niekoniecznie drugie.
>
> Ale tu inna sprawa - tu trzeba byc czujnym. I miec aplikacje zawsze pod
> reka ... czyli w telefonie.

Nie masz racji. Podstawą jest komputer i niejednokrotnie z dwoma
monitorami. Trzeba bowiem śledzić kurs - wykresy trochę zajmują. To
najważniejsza cecha.

Trochę mniej istotna, ale też ważna - zdecydowanie łatwiej jest
posługiwać się klawiaturą komputerową niż telefoniczną, która Ci
zasłonie znaczną część i tak maciupkiego ekraniku.

do góry

W dniu 2019-08-20 o 14:52, J.F. pisze:
> Użytkownik "Wojciech Bancer"  napisał w wiadomości grup
> dyskusyjnych:slrnqlnr31.2gb6.wojciech.bancer@pl-test
.org...
> On 2019-08-20, Kris <k...@g...com> wrote:
> [...]
>> Pozatym ostatnie wektory ataku to są ataki nie bezpośrednio
>> na konto, tylko bardziej udające strony do płatności online.
>> Tam to już w ogóle jest łatwiej, bo przecież masz tylko
>> dwa ekrany:
>> - formatka do loginu i hasła
>> - stronę do autoryzacji transakcji
>
>> I jedyne miejsce gdzie możesz wychwycić że coś się nie
>> zgadza, to komunikat autoryzacyjny w SMS lub Push,
>> bo na ekranie Ci się wszystko będzie zgadzać.
>
> A tak swoja droga - ta dyrektywa ma przeciez umozliwiac zarzadzanie
> kontem przez strony innej firmy.
>
> Jest przewidziana jakas procedura weryfikacji tych innych firm i
> dostepow przez nie, czy mozna sie spodziewac calej masy falszywek ?

https://legalgeek.pl/mala-instytucja-platnicza-licen
cja-dla-fintechu-wymogi-prawne/

--
Pete

do góry

Milek wczoraj ogłosił zmiany (też mają refleks, zmiany wchodzą od 14 września -
ciekawe, czy ktoś się poskarży i czy dostaną karę) - ale dużo rozsądniejsze - choć z
tym też można polemizować, czy nie będą jedynie upierdliwe - a bezpieczeństwa nie
zwiększą:

1) raz na 90 dni poprosimy Cię o zatwierdzenie logowania H@słem SMS lub Autoryzacją
Mobilną.
(no i właśnie - upierdliwe będzie, a czy przed czymś ochroni? Może właśnie te 90 dni
to stąd, że dopiero teraz zmiany ogłaszają)

2) gdy będziesz sprawdzać historię transakcji starszą niż 90 dni, możemy Cię poprosić
również o potwierdzenie tej operacji H@słem SMS lub Autoryzacją Mobilną
(ciekawe, przed czym ma to chronić)

3) transakcje kartami w Internecie z wykorzystaniem zabezpieczenia 3D-Secure także
potwierdzisz H@słem SMS lub Autoryzacją Mobilną
(a to jest w ogóle dziwne, przecież właśnie na tym polega 3DS - czy też może trzeba
będzie podwójnie autoryzować? Swoją drogą paypal wciąż nie używa 3DS).

do góry

On 2019-08-20, J.F. <j...@p...onet.pl> wrote:

[...]

> A to swoja droga - czemu na telefonie dedykowany program, a na
> komputerze przegladarka.

Bo dedykowany program może odczytać kontakty, pozycję, może otrzymać
pusha i obsłuży autoryzację biometryczną. Tak z grubsza.
Czyli więcej i bezpieczniej niż przez stronę.

--
Wojciech Bańcer
w...@g...com

do góry

Szymon <...@w...pl> writes:

> Zastanowiło mnie coś innego. Gdy podaję kod SMS do autoryzacji
> przelewu to przepisuję go w całości. Tymczasem kod wyświetlony na
> tokenie stanowił jedynie część hasła. Kradzież tokena nie jest zatem
> problemem, bo przepisanie wskazania nic nie da. Przepisanie wskazania
> SMS - owszem.

Nie, wtedy także potrzebne jest hasło - do logowania.

> Czy wprowadzenie kombinacji hasło+SMS nie spowodowałoby wzrostu
> bezpieczeństwa?

Tak już przecież jest. Tyle że nie wpisujemy hasła w tym samym czasie,
a nieco wcześniej - różnica nieistotna.

> Pewnym ryzykiem jest "wirus", który przekazywałby kod SMS przestępcom.

Nie, zakładając, że ktoś czyta treść SMSa i porównuje ją z tym, co
chciał zrobić.

> Tu token także lepiej się sprawdza.

Nie, token nie ma związku z treścią dyspozycji.

> Nadal jest jednak problem z fałszywą stroną. Klient wchodzi na
> podstawioną stronę, podaje login/hasło, powiedzmy że się nie
> orientuje, iż jest na podstawionej, wpisuje przelew, SMS. Przestępcy
> mają login, hasło, SMS. Logują się na właściwą i dokonują przelewu.

To wymaga zignorowania treści SMSa. Możliwe, ale jednak mało
prawdopodobne, zwłaszcza jeśli np. suma się (bardzo) nie zgadza.

> W przypadku tokena i fałszywej strony działania hakera musiałby się
> odbyć w tym samym czasie. Czyli logowanie, przelew.

Nie, to robi automat, niezależnie od rodzaju haseł, tokenów itd.
Dla niego bez różnicy.

> Sytuacja jednak
> się komplikuje przy haśle maskowanym. Szanse, iż klient wstuka na
> fałszywce te same pola, o które poprosi hakera oryginalna strona są
> małe.

Dla automatu bez różnicy. Fałszywa strona prosi klienta o te same pola,
których chce bank. Nie ma tu żadnych komplikacji, hasła maskowane,
wpisywane myszą itd. nic w tym kontekście nie zmieniają.

> A gdyby tak system pytał np. o 3 z 6 wskazań tokena plus 3
> dowolne znaki hasła? Czy taka okoliczność poprawiłaby bezpieczeństwo?

Nie, byłoby gorzej - szansa na trafienie 3 znaków to 0,1% - przy ataku
na 1000 osób statystycznie ok. 1 osobę uda się trafić w ogóle bez
dostępu do kodu z tokena.
To obecnie nieistotne oczywiście.

> Zastanowiła mnie jeszcze jedna rzecz. Powiedzmy, że wchodzę na
> fałszywkę. Chcę zrobić przelew, w znakomitej większości korzystam ze
> zdefiniowanych. Haker nie może wiedzieć, jakie mam przelewy
> zdefiniowane w systemie. Jeśli zatem widzę, że lista jest pusta to czy
> nie jest to wystarczającym sygnałem ostrzegającym dla klienta, że ze
> stroną coś jest nie tak?

Lista nie jest pusta (dlaczego miałaby być), ale oczywiście zagrożeniem
jest wykonywanie przelewu - lub innej operacji - która wymaga
dodatkowego kodu. Jeśli przelewy na zdefiniowane konta nie wymaga
takiego kodu, to - zakładając że owe konta są bezpieczne - nie ma tu
wielkiego zagrożenia (innego niż późniejsza konieczność odzyskiwania
pieniędzy od np. wspólnoty mieszkaniowej itp).
--
Krzysztof Hałasa

do góry

"J.F." <j...@p...onet.pl> writes:

> Kolejna sprawa, ze banki jak widac chca odejsc od SMS i autoryzacja
> bedzie w aplikacji.

To jest niebezpieczne rozwiązanie, ponieważ telefon staje się jedynym
punktem oporu. Przejęcie kontroli nad telefonem = kontrola nad kontem.

Hasła SMS nie dlatego są mocne że nie da się ich przechwycić, zmienić
itd. (owszem da się), tylko dlatego, że to jest kanał informacyjny
praktycznie całkowicie niezależny od komputera. Oczywiście, jeśli
komputerem nie jest telefon, który dostaje owe SMSy.
--
Krzysztof Hałasa

do góry

"J.F." <j...@p...onet.pl> writes:

>> Tam też było tak, że do wpisania trzeba było podać hasło+wskazanie
>> tokena.
>
> Ale to nie to samo co token z klawiaturka, ktorego zlodziej nie
> odblokuje.

Różnica nieistotna - założenie jest takie że złodziej, który ma dostęp
do komputera ofiary, nie ma dostępu do tokena (innego niż gdy user
wpisuje kod z tokena).

>>> W dodatku 3 cyfry z tokena to zaczyna byc juz niebezpiecznie malo -
>>> mozna probowac w ciemno, a noz sie trafi ..
>>To mało prawdopodobne.
>
> 1:1000. Tysiac prob i trafiles. Robiac dwie dziennie - efekt w ciagu
> niecalych dwoch lat.
> Ale majac namierzonych 10 frajerow - juz co dwa miesiace.

W przypadku botnetu, który "jest obecny" na 300 tysiącach komputerów -
może nawet nieco szybciej.
--
Krzysztof Hałasa

do góry

"J.F." <j...@p...onet.pl> writes:

>>I dalej:
>> "Pamiętaj, że Twoje urządzenie mobilne to klucz do Twoich finansów!
>> Jego utrata lub przejęcie przez przestępców może skutkować
>> przejęciem konta bankowego, a w rezultacie utratą środków
>> pieniężnych."
>
> Ale to samo mialbys z tokenem.

Jasne że nie.
Zakładając, że ktoś w ogóle nosiłby token przy sobie (żeby dało się go
ukraść, zgubić itd) - sam token nic nie daje nikomu.
Nawet nie wiadomo, że to token z banku (chociaż oczywiście można to
założyć).

> Nie akceptuje ActiveX ? ... od tego sie chyba odchodzi, javascript
> potrafi duzo.

A w ogóle były jakieś strony bankowe z ActiveX? Przecież tego nie dałoby
się używać nie z MS Explorerem(?).

> Czy jednak bezpieczenstwo dedykowanej aplikacji ... czy po prostu chca
> przy okazji wiecej danych zgromadzic - liste kontaktow np :-)

Pewnie tak, aplikacja może móc więcej niż jakaś tam strona.
Z drugiej strony, teoretycznie aplikacja może zorientować się, że ktoś
używa nie takiego sprzętu/oprogramowania (np. starego, ze znanymi
dziurami, z odpalonym trojanem itd). Aczkolwiek liczyć na to bym nie
liczył.
--
Krzysztof Hałasa

do góry

Krzysztof Halasa <k...@p...waw.pl> writes:

[...]
>
> A w ogóle były jakieś strony bankowe z ActiveX?

Była chyba jakaś chora implementacja w śp. BPH w zeszłym tysiącleciu.

> Przecież tego nie dałoby się używać nie z MS Explorerem(?).

No i sie nie dało.

KJ

--
http://wolnelektury.pl/wesprzyj/teraz/
Accordion, n.:
A bagpipe with pleats.

do góry

Dnia Tue, 20 Aug 2019 21:12:21 +0200, Krzysztof Halasa napisał(a):
> "J.F." <j...@p...onet.pl> writes:
>>>I dalej:
>>> "Pamiętaj, że Twoje urządzenie mobilne to klucz do Twoich finansów!
>>> Jego utrata lub przejęcie przez przestępców może skutkować
>>> przejęciem konta bankowego, a w rezultacie utratą środków
>>> pieniężnych."
>>
>> Ale to samo mialbys z tokenem.
>
> Jasne że nie.
> Zakładając, że ktoś w ogóle nosiłby token przy sobie (żeby dało się go
> ukraść, zgubić itd) - sam token nic nie daje nikomu.

Gdzies jest - wiec ukrasc sie da. W domowym sejfie przechowujesz ?

Fakt - tokena mozna jakos zabezpieczyc, a banki wlasnie wymuszaja
przejscie na urzadzenie osobiste, ktore z natury zabierasz ze soba,
czasem w niebezpieczne miejsca - basen, plaza ...

> Nawet nie wiadomo, że to token z banku (chociaż oczywiście można to
> założyć).

No, jak Wojtek ma 30 tokenow, to moze byc pewien problem ... choc
pewnie sobie opisal ktory do czego :-)

>> Nie akceptuje ActiveX ? ... od tego sie chyba odchodzi, javascript
>> potrafi duzo.
>
> A w ogóle były jakieś strony bankowe z ActiveX? Przecież tego nie dałoby
> się używać nie z MS Explorerem(?).

Zeszlo na forex - a tam wykresy i wykresy ... java ?

>> Czy jednak bezpieczenstwo dedykowanej aplikacji ... czy po prostu chca
>> przy okazji wiecej danych zgromadzic - liste kontaktow np :-)
>
> Pewnie tak, aplikacja może móc więcej niż jakaś tam strona.

Lokalizacje zapamietac, fotke zrobic, odcisk palca.
Moze nawet karte autoryzowac tylko gdy telefon w poblizu ...

> Z drugiej strony, teoretycznie aplikacja może zorientować się, że ktoś
> używa nie takiego sprzętu/oprogramowania (np. starego, ze znanymi
> dziurami, z odpalonym trojanem itd). Aczkolwiek liczyć na to bym nie
> liczył.

Tez bym specjalnie nie liczyl. Za to komunikacja moze byc lepiej
sprawdzana.

Ale poszlo o to, ze na telefony banki aplikacje robia, a na komputery
nie. Czemu? W czym komputery lepsze/gorsze.

J.

do góry