Tak, udało się, tym razem łączny dystans to 1200 kilometrów. W tym roku dystans nie był celem samym w sobie, chodziło mi przede wszystkim o utrzymanie nawyku i to udało się zrealizować. Trzy razy w tygodniu (z reguły – poniedziałek, środa i piątek) czuję wewnętrzną presję by pójść pobiegać. Oczywiście zdarzały się tygodnie, gdy nie udało się tego osiągnąć, ale to były raczej odstępstwa od reguły, zwykle spowodowane „obiektywnymi trudnościami”.
No dobrze, więc co z tą kartą / Apple Pay? Rozważmy dwa scenariusze:
PIN karty to typowo 4 cyfry. Daje to 10 000 możliwych kodów PIN. Do tego z reguły są trzy próby, czyli szansa powodzenia to (mniej więcej) 1 / 3 333. W praktyce można byłoby pokusić się o sprawdzenie najczęściej występujących kodów PIN co szanse powodzenia zwiększyłoby jeszcze bardziej (patrz: PIN analysis). Można jeszcze dyskutować, czy kody PIN do kart są wybierane przez użytkowników, czy ustawiane w sposób losowy przez bank, jak często klienci korzystają z opcji zmiany PINu (jeśli taka jest udostępniana), ale nie jest to istotne dla tej dyskusji.
Co z biometrią? W tym przypadku kluczowy jest parametr FAR (False Acceptance Rate lub False Match Rate – patrz: biometrics). W przypadku czytników wykorzystywanych obecnie w telefonach parametr ten ma wartość 1:50000, czyli zaczynamy z nieco lepszego poziomu, niż w przypadku PIN. No właśnie, zaczynamy. W przypadku biometrii też mamy kilka prób (trzy), więc można mówić o szansie mniej więcej na poziomie 1 / 16 666. Całość pogarsza się jeszcze, gdy dodany jest więcej niż jeden odcisk palca.
Warto też zwrócić uwagę na to, jak w tym kontekście wypada FaceID.
Oryginał tego wpisu dostępny jest pod adresem To co z tą kartą?
Autor: Paweł Goleń
Załóżmy, że gubisz:
Pytanie, co jest bardziej prawdopodobne:
Oryginał tego wpisu dostępny jest pod adresem Zagadka (karta vs. Apple Pay)
Autor: Paweł Goleń
Wspominałem już, że regularnie słucham różnych podcastów, bo pozwala mi to „odzyskać” trochę czasu przez robienie dwóch rzeczy na raz. Jednym z podcastów, które słucham, jest Hackable. Słucham, ale coraz częściej staje się on wypełniaczem czasu niż czymś, czego słucham uważnie. Dlaczego? Poziom. Podcast zwykle zaczyna się budującą napięcie sceną z jakiegoś znanego filmu lub serialu (oczywiście z hackerem w tle), a potem? Potem jest gorzej.
Właśnie, z tym gorzej mam pewien dylemat – nie wiem, czy problemem jest podcast (jego zawartość merytoryczna), czy raczej ja. Przykładem może być najnowszy epizod, Prying Eyes. Mamy rok 2018 a tematem przewodnim tego odcinka jest szyfrowanie (dysku w laptopie), a wielkim odkryciem jest to, że niezaszyfrowany dysk można podłączyć do innego komputera i uzyskać dostęp do danych. Szok! Brakowało tylko stwierdzenia, że kiedy usuwamy pliki z dysku to nie usuwamy ich naprawdę.
Po krótkiej refleksji – podcast jest w miarę OK, jest po prostu adresowany do innego odbiorcy niż ja. Jeśli ktoś z Was szuka podcastu poruszającego podstawowe tematy związane z bezpieczeństwem, Hackable to całkiem niezły wybór.
Oryginał tego wpisu dostępny jest pod adresem Hackable
Autor: Paweł Goleń
W tym roku nawet szybciej niż w ubiegłym (patrz też: 1103).
Oryginał tego wpisu dostępny jest pod adresem 1000 (2018)
Autor: Paweł Goleń
...i na razie rozbijam się o ścianę. Obiekt testów wybrałem niezbyt ambitny – swój własny blog. Pierwsze zadanie – crawling (patrz: Burp's new crawler). Niestety, do tej pory nie udało mi się doczekać końca tego zadania (kilka podejść w kilku kolejnych wersjach beta). Crawler wysyła ponad 20k requestów i nadal końca nie widać.
Dla porównania:
Kompletnie pomijając kwestię dokładności oraz czas trwania – w przypadku starszej wersji Burp oraz OWASP ZAP najistotniejsze jest to, że spidering się kończy.
Oryginał tego wpisu dostępny jest pod adresem Próbuję nowego Burpa i...
Autor: Paweł Goleń
Korzystam z wielu usług oferowanych przez Google. Korzystam, ale im nie ufam. Nie, nie chodzi o to, że ktoś czyta moje maile albo przegląda wydarzenia w kalendarzu. Chodzi o to, że usługa, z której korzystam może sobie zniknąć. Ot tak.
Tym razem chodzi o Inbox. Korzystam z tej usługi od kiedy tylko było to możliwe i pasuje mi dużo bardziej niż Gmail. Mówię to przede wszystkim o aplikacji mobilnej. I co? I to:
Inbox by Gmail is going away at the end of March 2019. Use the new Gmail to help you get more done and continue your conversations without interruption.
Oryginał tego wpisu dostępny jest pod adresem Google znowu to zrobi(ło)
Autor: Paweł Goleń
Dawno, dawno temu pisałem, że byłbym w stanie zapłacić za usługę polegającą na doborze i prezentowaniu interesujących mnie treści. Dobór miałby polegać na merytorycznej weryfikacji zawartości, prezentacja – cokolwiek (to były jeszcze zamierzchłe czasy gdy RSS był nowy i trendy). Cóż, dalej czekam na taką usługę.
Usług oferujących feed newsów jest sporo, wystarczy wymienić Google News (Wiadomości Google), czy Wiadomości (Microsoft), do tego taki feed jest oferowany w przeglądarkach (choćby Chrome, Edge). W dalszym ciągu to nie to.
Po pierwsze jakość informacji – przeraźliwie niska. Nie, nie jest dobrze, gdy 50%25 kanału “Nauka i technika” stanowią artykuły o grach komputerowych. Do tego informacje o nowych telefonach/tabletach/zegarkach oraz “spadochroniarze” typu “Kandydat na prezydenta ugodzony nożem” (przykład błędnej klasyfikacji treści). Podobnie w innych kategoriach. W zasadzie nie – w porównianiu z innymi kategoriami “Nauka i technika” nie wypada tak źle.
Po drugie duplikacja treści - OK, rozumiem, ten sam temat może być poruszany w wielu źródłach, wolałbym jednak, by w takich przypadkach następowało grupowanie treści. Niby próby są podejmowane, ale wciąż daleko temu do używalności (nie mówiąc o doskonałości).
Po trzecie niedopasowanie treści do odbiorcy - zarówno Microsoft jak i Google mają mnie dość dobrze sprofilowanego (w to nie wątpię). Czy nie można tej wiedzy wykorzystać do tego, by przestać prezentować mi treści, które mnie nie zainteresują? Co więcej, mimo możliwości oznaczania w aplikacji artykułów, które mnie (nie)interesują nie widzę wielkiego wpływu takich działań na prezentowanie później treści.
Po czwarte głupie pomysły EU wygoda użytkowania - nie, nie podoba mi się to, że po otwarciu strony z artykułem muszę się przeklikać przez kilka okienek informacyjnych o cookies, danych osobowych i tak dalej. Tak wiem, obowiązki informacyjne i tak dalej...
(....) i jest tego więcej...
Oryginał tego wpisu dostępny jest pod adresem Newsy są coraz gorsze
Autor: Paweł Goleń
Czekam na zakończenie The new month of Burp pr0n i możliwość przetestowania (w praktyce) opisywanych zmian. W tym samym czasie chciałbym porównać jego możliwości z OWASP ZAP.
Co do zasady nie mam złudzeń, Burp jest bardziej kompletnym, dopracowanym narzędziem, ale jest kilka obszarów, w których ZAP ma ciekawe pomysły. Choćby spider/crawler, który w Burp również ma zostać znacząco ulepszony (patrz: Burp's new crawler).
Jedna rzecz się nie zmieni, Burp nie stanie się narzędziem fire and forget. To, że nie jest on w stanie zaadresować błędów logiki biznesowej jest oczywistością, wyzwaniem mogą być również skanowanie prostych technicznych usterek jeśli skaner nie jest w stanie odtworzyć prawidłowej ścieżki wywołania danej funkcji. Tu też należy spodziewać się ulepszeń (patrz: Automatically maintaining session during scans), ale nie wierzę, że rozwiązanie będzie kompletne. Niemniej jednak z chęcią sprawdzę jak Burp będzie sobie radził choćby z ochroną przez CSRF, obecne rozwiązania, Using Burp's Session Handling Rules with anti-CSRF Tokens, do najwygodniejszych nie należy.
Jest jeszcze jedna rzecz, której brakuje mi i w Burp, i w ZAP – dokładnego logowania wszystkiego co jest wysyłane do serwera w celu późniejszej analizy. Tak, są rozszerzenia (Logger++), można zapisywać logi do pliku tekstowego, ale nie są to rozwiązania wygodne. Ciągle chyba najlepszym rozwiązaniem jakie widzę, to puszczenie całego ruchu przez kolejne proxy (np. Fiddler) i zachowanie również tych logów na wypadek, gdyby w przyszłości zaszła potrzeba przeanalizowania co (nie)zostało zrobione.
Oryginał tego wpisu dostępny jest pod adresem The new month of Burp pr0n
Autor: Paweł Goleń
Po drugim dniu konferencji mam pewien niedosyt. Agenda była ułożona w taki sposób, że prezentacje, które mnie interesowały najbardziej odbywały się często równolegle.
XSS is dead. We just don't get it. - tak, oddawna mamy (prawie) wszystko, co potrzebne by wygrać z XSS. Trzeba tylko z tego korzystać. Mimo wszystko jednak nie wierzę, że pozbędziemy się XSS w przewidywalnej przyszłości. To nie jest tak, że w developerach upatruję całego zła tego świata, ale z drugiej strony mam bolesną świadomość jak niektóre zespoły developerów są tworzone/kompletowane, jak często się zmieniają i jak wygląda poziom świadomości odnośnie secure coding.
A na tej prezentacji niestety nie byłem. Defense-in-depth techniques for modern web applications and Google's journey with CSP. Temat CSP jak najbardziej powiązany z prezentacją Mario. Tak, CSP jest fajnym narzędziem, ale jest skomplikowane. Bardzo. Jeśli ktoś potrafi z niego prawidłowo korzystać, prawdopodobnie jest w stanie użyć również pozostałych narzędzi do walki z XSS, więc CSP rzeczywiście pełni rolę dodatkowej linii obrony. A jeśli aplikacja jest, nazwijmy to, “kreatywna”, to stworzenie sensownej polityki nie jest zadaniem trywialnym (zakładając optymistycznie, że jest możliwe).
Kolejny slot, ten bolał mnie najbardziej – tutaj na odmianę trzy interesujące prezentacje:
Oryginał tego wpisu dostępny jest pod adresem Confidence 2018 (2)
Autor: Paweł Goleń