W ramach ćwiczeń rzucam temat związany z Application Security Verification Standards. Jakie są praktyczne korzyści z tytułowego wymagania i w jakich scenariuszach. Stosowne punkty w ASVS:
- V2.9 Verify that re-authentication is required before any application-specific sensitive operations are permitted.
- V3.7 Verify that the session id is changed on reauthentication.
Dla pobudzenia Waszej wyobraźni pytania:
- Jakie znacie aplikacje, które korzystają z tego mechanizmu?
- Czy korzystacie z tego rozwiązania w swoich aplikacjach (pytanie do nielicznych programistów)?
- Jakie operacje uznalibyście za application-specific sensitive operations w kontekście konkretnej aplikacji (do wyboru)?
- Co w przypadku, gdy na stacji działa malware?
- Dlaczego w bankach wymagane jest coś więcej do autoryzacji transakcji?
W temacie ostatniego pytania wiele razy się wypowiadałem w odniesieniu do bankowości internetowej, zresztą pośrednio odpowiadając na pytanie drugie. Ale Wasze zdanie wcale nie musi być takie samo, jak moje :)
W teorii, bo poza ponownym uwierzytelnieniem jest jeszcze kilka zabezpieczeń, np. bardzo krótki czas życia nieaktywnej sesji.
Więc kiedy hacking.pl się podniecał odkryciem tej straszliwej dziury to nie do końća było czym
W przypadku Allegro jest to o tyle ciekawe, że chronione są przede wszystkim dane innych ludzi - tzn kontrahentów. Podejrzewam, że zrobili to ze względu na ochronę danych osobowych.
W eBay jest to zrobione jakoś sprytniej, bo trudno badać ich aplikację z użyciem proxy w stylu Odysseus itd. Zawsze w takim przypadku eBay wywalał mnie z informacją o błędzie przekroczenia czasu komunikacji czy coś w tym stylu.
Uwierzytelnienie loginem i hasłem zapewnia autentyczność na poziomie podstawowym, wystarczającą do przeglądania danych konta i realizowania przelewów ustalonych.
Uwierzytelnienie tokenem/SMS zapewnia autentyczność i NIEZAPRZECZALNOŚĆ na poziomie średnim, niezbędną dla realizowania operacji, które mogą być podważane przez klienta.
Od lat tłuczemy naszym kolegom z administracji publicznej, że zróżnicowanie funkcji oraz ich poziomów jest niezbędne, ale jak grochem o ścianę.
W ten sposób zresztą zarżnięto faktury elektronicznego w Polsce, wymagając dla ich wystawiania podpisu kwalifikowanego, który zapewnia w/w funkcje na poziomie wysokim - co miało taki sam efekt, jaki miałoby żądanie podpisu notarialnego na fakturach papierowych.
W praktyce zapewnienie niezaprzeczalności polega na zmuszeniu użytkownika do wykonania czynności, które wykażą jego świadomą wolę z odpowiednim poziomem pewności ORAZ gromadzeniem różnych form materiału dowodowego na rzecz tego, kto te operacje wykonywał.
Jak widać, niezaprzeczalności nie da się zagwarantować bo użytkownik ma ZAWSZE PRAWO ZAPRZECZYĆ dowolnej wykonanej operacji. Cała zabawa z zapewnianiem niezaprzeczalności sprowadza się do posiadania dostatecznej liczby dowodów w celu przekonania sądu
Przytoczony przez Ciebie przypadek malware to odrębny problem POZIOMU PEWNOŚCI tej niezaprzeczalności. Najwyższy realny scenariusz to operacja wykonana na wyspecjalizowanym systemie w obecności notariusza - wszystko poniżej jest teoretycznie podważalne
Wracając do realnego życia, w rzeczywistości wystarczające są znacznie prostsze środki. Np. jak instalujesz OpenOffice to musisz przewinąć do końca licencję żeby nacisnąć Next. To jest doskonały przykład realizowania niezaprzeczalności znanej jako Non-Repudiation of Knowledge, który jest "wystarczająco skuteczny" w stosunku do potrzeb.
Wystarczająco, bo w większości przypadków sądowi wystarczy wykazanie, że producent dołożył wystarczającej staranności (best effort) dla upewnienia się, że dana osoba wykonuje operację świadomie.
Wykazanie wystarczającej/należytej staranności może nie być wystarczające przy sporze klient bank.
Dokładnie z tego powodu autoryzacja przelewu w bankach jest dwuetapowa:
1) najpierw wpisujesz do formularza dane beneficjenta, numer konta, kwotę
2) na następnym ekranie widzisz te dane w formie statycznej i dopiero je podpisujesz (autoryzujesz) hasłem jednorazowym
Jak słusznie zauważyłeś, w niektórych przypadkach istnieje ryzyko, że zgromadzony materiał nie wystarczy do podważenia wyparcia się w sądzie - albo, wyparcie jest z dużym prawdopodobieństwem prawidłowe. Stąd np. telefon do klienta z prośbą o dodatkową autoryzację ustną przy dużych przelewach albo jeśli np. transakcja jest realizowana z jakiegoś ponurego IP.
Pamiętam, że na OWASP Europe (http://www.owasp.org/images/e/e4/AppsecEU09_The_Bank_in_The_Browser_Presentation_v1.1.pdf) również kody SMS były prezentowane jako rozwiązanie nie do końca bezpieczne. Czekam na jakieś namacalne rezultaty OWASP Anti-Malware (http://www.owasp.org/index.php/OWASP_Anti-Malware_Project), bo idea jest ciekawa.
Ale wracając do samych kodów SMS to tam słowem-kluczem było "SIM swap", co w naszych warunkach jednak nie jest całkiem trywialne.
Bank to nie administracja publiczna, która może zmusić userów do używania nie pasującego mechanizmu bezpieczeństwa - patrz podpis kwalifikowany w ZUS.
Zresztą w ubiegłym roku któryś z bęcwałów doradzających rządowi domagał się wprowadzenia obowiązku stosowania podpisu kwalifikowanego do autoryzacji transakcji w bankach. Że bezpiecznie, i że będzie jednolicie.
Na szczęście bankowcy go szybko usadzili bo to by zarżnęło bankowość elektroniczną w Polsce tak samo jak zarżnęło e-faktury.
I żyją - jak widać wszystko sprowadza się do racjonalnej analizy ryzyka.
Różnica między klient wpisał odpowiedni kod, a klient przekazał "token", który potwierdza transakcję WRAZ Z JEJ ISTOTNYMI PARAMETRAMI jest, według mnie, niepomijalna.
Przy czym nie można ograniczyć się do rozwiązań technicznych, kwestie organizacyjne też mają tu sporo do "powiedzenia".
I tu bardziej w temacie tego podwątku. Jeśli do przekazywania danych do autoryzacji transakcji wykorzystuje się SMS, to by cały system działał, przejęcie przez atakującego tego kanału musi być trudne. W przypadku działających w naszym kraju operatorów komórkowych na razie kody SMS spełniają ten warunek, ale może się wkrótce okazać, że poziom bezpieczeństwa pieniędzy w banku będzie zależał od... operatora, u którego ktoś posiada telefon.