https://archive.mroczna-zaloga.org/ Paweł Goleń, blog - Zrzędzenie starego zgreda pl Serendipity - http://www.s9y.org/ Sat, 15 Mar 2025 22:14:52 GMT https://archive.mroczna-zaloga.org/templates/bulletproof/img/s9y_banner_small.png https://archive.mroczna-zaloga.org/ 100 21 https://archive.mroczna-zaloga.org/archives/662-re-authentication-is-required.html#c1306 https://archive.mroczna-zaloga.org/archives/662-re-authentication-is-required.html#comments https://archive.mroczna-zaloga.org/wfwcomment.php?cid=662 nospam@example.com (wampir) Zwróć uwagę na przejścia między HTTP i HTTPS. Fri, 24 Jul 2009 14:41:21 +0200 https://archive.mroczna-zaloga.org/archives/662-guid.html#c1306 https://archive.mroczna-zaloga.org/archives/662-re-authentication-is-required.html#c1303 https://archive.mroczna-zaloga.org/archives/662-re-authentication-is-required.html#comments https://archive.mroczna-zaloga.org/wfwcomment.php?cid=662 nospam@example.com (hip) czy podawanie dwa razy tego samego loginu i hasła (jak w Allegro), tylko po to, żeby zmienić session_id to nie jest głupota i strata czasu? Fri, 24 Jul 2009 13:52:12 +0200 https://archive.mroczna-zaloga.org/archives/662-guid.html#c1303 https://archive.mroczna-zaloga.org/archives/662-re-authentication-is-required.html#c1302 https://archive.mroczna-zaloga.org/archives/662-re-authentication-is-required.html#comments https://archive.mroczna-zaloga.org/wfwcomment.php?cid=662 nospam@example.com (wampir) Z moich doświadczeń empirycznych wynika, że zwykle sam kod SMS nie jest związany z parametrami transakcji i jedyna różnica między hasłami jednorazowymi z listy, to sposób ich dostarczenia. Fri, 24 Jul 2009 10:45:20 +0200 https://archive.mroczna-zaloga.org/archives/662-guid.html#c1302 https://archive.mroczna-zaloga.org/archives/662-re-authentication-is-required.html#c1301 https://archive.mroczna-zaloga.org/archives/662-re-authentication-is-required.html#comments https://archive.mroczna-zaloga.org/wfwcomment.php?cid=662 nospam@example.com (kravietz) Nie jestem pewien, czy kod przesyłany przez bank SMSem nie jest powiązany z danymi transakcji. To proste, w przeciwieństwie do haseł jednorazowych na kartkach. Ale to już dywagacje, bo implementacje są niejawne. Nawiasem mówiąc to co opisałeś to prawie kompletny token niezaprzeczalności wg ISO 13888 :) Fri, 24 Jul 2009 10:41:02 +0200 https://archive.mroczna-zaloga.org/archives/662-guid.html#c1301 https://archive.mroczna-zaloga.org/archives/662-re-authentication-is-required.html#c1298 https://archive.mroczna-zaloga.org/archives/662-re-authentication-is-required.html#comments https://archive.mroczna-zaloga.org/wfwcomment.php?cid=662 nospam@example.com (wampir) Ależ oczywiście, że bezpieczny podpis elektroniczny to przerost formy w przypadku bankowości elektronicznej. Ale już wykorzystanie w aplikacji zamiast "jawnego" SMS coś postaci hmac(dane transakcji, kod sms) w pewien sposób wiąże parametry transakcji z kodem SMS i można "bardziej" weryfikować, czy wykonana transakcja jest rzeczywiście tą, którą autoryzował klient. Dla klienta jest to całkowicie przezroczyste, bo jego aktywność w obu przypadkach sprowadza się do wpisania w stosowne pole kodu SMS. 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. Fri, 24 Jul 2009 10:29:16 +0200 https://archive.mroczna-zaloga.org/archives/662-guid.html#c1298 https://archive.mroczna-zaloga.org/archives/662-re-authentication-is-required.html#c1297 https://archive.mroczna-zaloga.org/archives/662-re-authentication-is-required.html#comments https://archive.mroczna-zaloga.org/wfwcomment.php?cid=662 nospam@example.com (kravietz) Nic nie jest do końca bezpieczne. Problem polega na tym, że jak w banku zrobisz ZBYT bezpiecznie to klienci uciekną. Bo bezpieczeństwo kosztuje i to obie strony. 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. Fri, 24 Jul 2009 09:42:18 +0200 https://archive.mroczna-zaloga.org/archives/662-guid.html#c1297 https://archive.mroczna-zaloga.org/archives/662-re-authentication-is-required.html#c1289 https://archive.mroczna-zaloga.org/archives/662-re-authentication-is-required.html#comments https://archive.mroczna-zaloga.org/wfwcomment.php?cid=662 nospam@example.com (wampir) A czy miała ku temu "jakieś wsparcie"? 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. Thu, 23 Jul 2009 17:11:14 +0200 https://archive.mroczna-zaloga.org/archives/662-guid.html#c1289 https://archive.mroczna-zaloga.org/archives/662-re-authentication-is-required.html#c1288 https://archive.mroczna-zaloga.org/archives/662-re-authentication-is-required.html#comments https://archive.mroczna-zaloga.org/wfwcomment.php?cid=662 nospam@example.com (Przemyslaw Skowron) :-) To może przy okazji... Kiedyś rozmawiałem z osobą reprezentującą firmę X, która prezentowała system do wykrywania podejrzanych transakcji. Podważyła pewność podpisywanej transakcji kodem z SMSa. Wtedy zapytałem czy czyta w SMSie informacje o transakcji, której dany kod dotyczy. Przyznała, że nie. Paweł, ci mniej "zwykli" też rzadko czytają. Thu, 23 Jul 2009 16:55:43 +0200 https://archive.mroczna-zaloga.org/archives/662-guid.html#c1288 https://archive.mroczna-zaloga.org/archives/662-re-authentication-is-required.html#c1287 https://archive.mroczna-zaloga.org/archives/662-re-authentication-is-required.html#comments https://archive.mroczna-zaloga.org/wfwcomment.php?cid=662 nospam@example.com (wampir) Zwróć uwagę, że przechowanie w bazie samego kodu jednorazowego, który w żaden sposób nie jest związany z parametrami wykonanej transakcji, jest niewystarczające. Przy okazji warto tu zwrócić uwagę na miejsce, gdzie kończą się możliwości czysto techniczne, a pojawiają się rozwiązania organizacyjne. Thu, 23 Jul 2009 16:52:10 +0200 https://archive.mroczna-zaloga.org/archives/662-guid.html#c1287 https://archive.mroczna-zaloga.org/archives/662-re-authentication-is-required.html#c1286 https://archive.mroczna-zaloga.org/archives/662-re-authentication-is-required.html#comments https://archive.mroczna-zaloga.org/wfwcomment.php?cid=662 nospam@example.com (wampir) ...i czego naturalną konsekwencją jest wykorzystanie SMS jako dodatkowego, niezależnego i potencjalnie niekontrolowanego przez atakującego kanału komunikacji, którym przekazywany jest nie tylko kod autoryzacyjny, ale również informacje o transakcji, która ma być wykonana (przynajmniej jej istotne szczegóły). Co ciekawe rozmawiając z wieloma "zwykłymi" użytkownikami bankowości internetowej dowiaduję się, że nie patrzą w ten sposób. SMS traktują wyłącznie jako nośnik kodu autoryzacyjnego. Thu, 23 Jul 2009 16:46:05 +0200 https://archive.mroczna-zaloga.org/archives/662-guid.html#c1286 https://archive.mroczna-zaloga.org/archives/662-re-authentication-is-required.html#c1285 https://archive.mroczna-zaloga.org/archives/662-re-authentication-is-required.html#comments https://archive.mroczna-zaloga.org/wfwcomment.php?cid=662 nospam@example.com (Przemyslaw Skowron) Niestety prezentacja danych w formie statycznej, etap drugi, to nadal za mało. Aktualnie "dostępny" malware podmienia dane także w odpowiedzi serwera prezentując niewinny przelew. Thu, 23 Jul 2009 16:36:24 +0200 https://archive.mroczna-zaloga.org/archives/662-guid.html#c1285 https://archive.mroczna-zaloga.org/archives/662-re-authentication-is-required.html#c1284 https://archive.mroczna-zaloga.org/archives/662-re-authentication-is-required.html#comments https://archive.mroczna-zaloga.org/wfwcomment.php?cid=662 nospam@example.com (kravietz) To też część odpowiedniej KONSTRUKCJI mechanizmu niezaprzeczalności (PN-ISO/IEC 13888 nazywa go "tokenem"). 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. Thu, 23 Jul 2009 16:16:21 +0200 https://archive.mroczna-zaloga.org/archives/662-guid.html#c1284 https://archive.mroczna-zaloga.org/archives/662-re-authentication-is-required.html#c1281 https://archive.mroczna-zaloga.org/archives/662-re-authentication-is-required.html#comments https://archive.mroczna-zaloga.org/wfwcomment.php?cid=662 nospam@example.com (wampir) Szczególnym przypadkiem może być sytuacja, w której klient nie wypiera się wykonania operacji, ale jej "treści". Przy niektórych implementacjach autoryzacji transakcji zebrany materiał dowodowy jest łatwiejszy do podważenia, niż przy innych. Wykazanie wystarczającej/należytej staranności może nie być wystarczające przy sporze klient bank. Thu, 23 Jul 2009 15:50:05 +0200 https://archive.mroczna-zaloga.org/archives/662-guid.html#c1281 https://archive.mroczna-zaloga.org/archives/662-re-authentication-is-required.html#c1275 https://archive.mroczna-zaloga.org/archives/662-re-authentication-is-required.html#comments https://archive.mroczna-zaloga.org/wfwcomment.php?cid=662 nospam@example.com (kravietz) Zauważ, że "zagwarantowanie" czegoś jest cechą często i błędnie przypisywaną funkcji niezaprzeczalności. 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. Thu, 23 Jul 2009 12:45:09 +0200 https://archive.mroczna-zaloga.org/archives/662-guid.html#c1275 https://archive.mroczna-zaloga.org/archives/662-re-authentication-is-required.html#c1274 https://archive.mroczna-zaloga.org/archives/662-re-authentication-is-required.html#comments https://archive.mroczna-zaloga.org/wfwcomment.php?cid=662 nospam@example.com (wampir) Z tą niezaprzeczalnością to przynajmniej w części implementacji może być różnie. Przykładowo w przypadku tokenu ("klasyczne" rozwiązanie - wpisanie aktualnego wskazania tokenu) można udowodnić co najwyżej, że osoba znająca wskazanie tokenu (w założeniu "posiadacz" konta) wykonała daną operację. Sama "treść" transakcji może być jednak podważana przez klienta (niech bank udowodni klientowi, że chciał on zrealizować właśnie taką a nie inną transakcję, a ta, która poszła do banku to efekt działania malware na jego stacji). Thu, 23 Jul 2009 12:22:55 +0200 https://archive.mroczna-zaloga.org/archives/662-guid.html#c1274