[Owasp-poland] Kryteria oceny bezpieczeństwa bankowości internetowej

Paweł Goleń pawel.golen at gmail.com
Tue May 18 08:44:20 EDT 2010


On 2010-05-18 13:14, Tomasz Dudzisz wrote:

> Za dwa lata E51 będzie zabytkiem :)

Pamiętaj, że banki nie mogą ograniczyć się w swoim "celowaniu"
mechanizmów tylko do tych ludzi, którzy korzystają z "aktualnych"
technologii. Wprowadzenie autoryzacji przez kody SMS wiązało się z
protestami pewnej grupy klientów, którzy podnosili argument, że nie ma
obowiązku posiadania telefonu komórkowego i podawania jego numeru
bankowi. O ile w tym przypadku grupa "straconych" klientów była
niewielka (a i ich "jakość" rozumiana jako ilość pieniędzy, które można
na nich uzyskać była niewielka), to wprowadzanie dalszych wymagań (np.
"wypasioność" telefonu) może niekorzystnie wpływać na tak dużą grupę
obecnych/potencjalnych klientów, że ostatecznie rozwiązanie nie zostanie
wdrożone. Okaże się po prostu nieopłacalne. To takie luźne zwrócenie
uwagi na to, że nie można ograniczać się tylko do technologii, ważny
jest jeszcze biznes :)

> Generalnie zdanie mamy podobne co do przyszłości tokenów CR. Z tym,
> że nie widzę zupełnie przyszłości dla SMSów... Wady SMSów na tę
> chwilę:
> 
> - koszt (w przypadku banków trudno pomijalny, gwarancja dostarczenia
>  SMSa kosztuje dodatkowo)

Oczywiście, to jest słuszna uwaga. Dlatego też banki rozglądają się za
alternatywnymi sposobami. Rozwój technologii daje im dodatkowe opcje,
choćby różne (podkreślam - RÓŻNE) implementacje CR na komórki.

> - zawodność (np brak zasięgu, przeciążenia sieci, w przypadku
> zwykłych SMSów brak gwarancji dostarczenia)

Ten argument jest chyba nieco mniej istotny w tej chwili, choć ciężko go
wykluczyć w przyszłości. Czy ktoś słyszał o problemach klientów z
niedochodzącymi kodami SMS? Dużo częściej można usłyszeć o problemach z
logowaniem się do systemu. Nie mam tu jednak wystarczającej ilości
danych, opieram się raczej na założeniu, że jesteśmy wyjątkowo marudnym
narodem i gdyby taka sytuacja miała miejsce, ktoś by się poskarżył, a
media nie omieszkały tematu podchwycić.

> Prawdopodobieństwo tego, że ktoś w locie podmieni wektory składające
> się na kod challenge (nr konta, nr transakcji, typ transakcji, czas,
> zmienne przypisane do konta itp) by dały taki sam output w postaci
> kodu response, który zaakceptuje bank jest dość małe.

To już zależy od konkretnego wdrożenia (implementacji). Przykładowo
jeśli na wejściu do urządzenia/aplikacji jest ciąg 8 znaków jako
challenge, to jest to JEDEN "wektor". Nie trzeba go podmieniać, atak
malware wygląda następująco:

- użytkownik podaje dane przelewu,
- malware przechwytuje dane klienta, wysyła do serwera inne dane przelewu,
- serwer zwraca stronę z danymi przelewu i challenge,
- malware podmienia na wyświetlanej stronie dane przelewu na oryginalne,
pozostawia kod challenge wygenerowany przez serwer,
- użytkownik przepisuje challenge do aplikacji, przesyła response do
serwera,

Zadanie jest trywialne. Użytkownik nie ma możliwości sprawdzenia, jaką
operację rzeczywiście autoryzuje.

Sytuacja zmienia się, jeśli użytkownik do aplikacji ma przepisać np.
challenge, jakieś cyfry z numerów konta źródłowego/docelowego i kwotę
przelewu. Dalej nie jest to jednak w 100% bezpieczne, bo można zrobić
"kolizję" numeru konta (już podsyłałem linka na ten temat). To samo
dotyczy również kodów SMS, one również nie zawierają pełnych numerów konta.

Można wyobrazić sobie również kody QR, w których będzie przekazane np.:
- challenge (np. hash z danych transakcji),
- dane operacji,
- MAC (lub inny "podpis") całości,

Aplikacja po odczytaniu danych wyświetli dane transakcji użytkownikowi,
który następnie przepisze do aplikacji wygenerowany response. Response
będzie właściwy wyłącznie dla danego challenge, który z kolei jest
wprost zależny od danych operacji (bo bankowość to nie tylko przelewy!).
MAC w tym wypadku dawałby pewność (no, przynajmniej bardzo duże
prawdopodobieństwo), że challenge rzeczywiście dotyczy danych
transakcji, które są wyświetlane użytkownikowi).


> No i tokeny CR to chyba jedyna metoda zabezpieczenia przed
> phishingiem w tym momencie (a raczej jego skutkami) - w przypadku SMS
> tego chyba nie ma?

Możesz rozwinąć tą myśl?

-- 
Paweł Goleń
mailto:pawel.golen at gmail.com


More information about the Owasp-poland mailing list