Uwaga na mobilne oszustwa
-
- Patryk Królikowski,
- 05.11.2012, godz. 08:20
Coraz popularniejsze są również tokeny, w tym C/R, w postaci sprzętowej lub aplikacji (także na komórkę). W ich przypadku w trakcie wykonywania transakcji podawany jest kod, który użytkownik musi przepisać do tokena, aby na jego podstawie został wygenerowany inny kod do przepisania w serwisie transakcyjnym. Wiele mówi się o znacznym bezpieczeństwie tokenów C/R. Dotyczy to również tych aplikacyjnych pod warunkiem jednak, że został on dobrze napisany i nie jest poprzetykany podatnościami. Zdarzają się też tokeny aplikacyjne, które mają w sobie zaszyty certyfikat, co dodatkowo zwiększa poziom ich bezpieczeństwa.
Mówiąc o bezpieczeństwie transakcji elektronicznych, nie sposób zapominać o systemach wspomagających, które pomagają w wykryciu podejrzanych zachowań - tzw. narzędzi antyfraudowych. O rozwiązaniach tego typu pisaliśmy już na łamach "Networlda".
NW: Jakie warunki powinna spełniać metoda autoryzacji transakcji, aby w obliczu ataków Man in the Mobile mogła być uważana za wystarczająco bezpieczną?
MB: Jeśli mówimy o bankowości mobilnej, tzn. dostępie do systemu bankowego z urządzenia mobilnego (a w szczególności dostępie z dedykowanej aplikacji), to największe zagrożenia w kontekście ataków MitMo są związane z autoryzacją transakcji dowolnych. Paradoksalnie, bankowość mobilna spowodowała, że znów mamy sytuację podobną do tej sprzed lat. Wtedy komputer osobisty był używany do definiowania przelewu i jego autoryzacji. Wtedy pojawiły się ataki Man in the Middle, które "w locie" i w sposób niewidoczny dla użytkownika podmieniały dane przelewów, a użytkownik nie wiedział, jaką transakcję autoryzuje. Wymyślono wtedy, że urządzenie mobilne będzie drugim, niezależnym kanałem do weryfikacji procesu autoryzacji transakcji.
Szczególnie dwie metody autoryzacji są godne uwagi:
• kody przesyłane wiadomością SMS (treść wiadomości zawiera szczegóły transakcji - użytkownik weryfikując numer rachunku może stwierdzić, czy zdefiniowana transakcja w bankowości internetowej jest poprawna)
• autoryzacja za pomocą funkcji kryptograficznych HMAC lub podobnych (użytkownik przepisuje z faktury do urządzenia mobilnego kluczowe dane - np. fragment rachunku docelowego, kwotę i generuje kod, który następnie wpisuje w systemie bankowości internetowej, aby autoryzować transakcję).
Powyższe przykłady dotyczą typowej bankowości internetowej, gdzie telefon jest tylko niezależnym (out-of-band) kanałem weryfikującym przelew.
W bankowości mobilnej, znów mamy jedno urządzenie - tym razem telefon, który służy do definiowania przelewu oraz jego autoryzacji. Teoretycznie wystarczy więc, że intruz przejmie kontrolę nad urządzeniem mobilnym lub komunikacją sieciową, aby autoryzować dowolną transakcję.
Czy takie zagrożenie jest realne? Tutaj bardzo dużo zależy od samego użytkownika. Ataki, które do tej pory miały miejsce, wynikały głównie z naiwności klientów banku. Istotne jest również bezpieczeństwo samego urządzenia mobilnego. Kolejną ważną zasadą jest posiadanie aktualnej wersji systemu operacyjnego, gdyż bardzo często stare wersje mają poważne luki w bezpieczeństwie. Nie zalecamy również zdejmowania zabezpieczeń z telefonów (rooting/jailbreak). Takie działanie wyłącza niektóre mechanizmy bezpieczeństwa i ułatwia wykonanie ataku. Należy pamiętać też o ustawieniu złożonego kodu PIN/hasła do urządzenia mobilnego. A jaka metoda autoryzacji jest bezpieczna? Żadna obecnie stosowana w urządzeniach nie daje 100% ochrony. Najlepiej abyśmy na urządzeniach mobilnych wykonywali jedynie transakcje zdefiniowane. W przypadku autoryzacji transakcji mogą być stosowane różne rozwiązania techniczne, które nie zawsze są "widoczne" dla użytkownika.
NW: Jakie metody autoryzacji można uznać za godne polecenia dla Kowalskiego?
MB: W przypadku bankowości internetowej - stosować autoryzację transakcji opartą na wiadomości SMS lub tzw. software token, gdzie szczegóły transakcji są wykorzystywane przy generowaniu kodu autoryzującego. W przypadku bankowości mobilnej - starać się wykorzystywać transakcje zdefiniowane.
