Już jakiś czas naszła mnie taka refleksja – czy można rozmawiać szybciej? Chodzi mi o to, że polskie podcasty z reguły słucham 1.5x szybciej niż w oryginale, te angielskojęzyczne co najmniej 1.25x. Zacząłem jednak zauważać pewien problem – w normalnej konwersacji z (normalnymi) ludźmi zaczynam mieć wrażenie, że strasznie wolno mówią...
Oryginał tego wpisu dostępny jest pod adresem Szybciej...
Autor: Paweł Goleń
Prosty przykład, Pomnik Cesarzowej Achai , tom 2
Różnica 3 PLN może nie jest powalająca i jeśli uwzględnić dodatkowo fakt, że po książkę tradycyjną muszę pofatygować się do punktu odbioru – zaniedbywalna. Z drugiej jednak strony wydaje mi się, że koszt wyprodukowania tradycyjnej książki jest nieco wyższy, niż ebooka... A tak z innej beczki, książka Security Engineering: A Guide to Building Dependable Distributed Systems to jakieś 9 funtów różnicy między wersją papierową i elektroniczną. Tylko, że ta sama książka dostępna jest za darmo: [Security Engineering — The Book. Polecam :)
Oryginał tego wpisu dostępny jest pod adresem Dlaczego NIE kupuję książek na Kindla (polskich)
Autor: Paweł Goleń
Teoretycznie znam swój rozmiar 34/32. W praktyce nawet spośród spodni w tym rozmiarze jedynie niewielki procent pasuje na mnie. Ja jestem staromodny, lubię proste spodnie, czyli po prostu najchętniej REGULAR/STRAIGHT. Ewentualnie może być LOOSE o ile nie są zbyt workowate. Ale nie, teraz większość spodni, które widzę w sklepach nie dość, że są SLIM, to jeszcze TAPERED. Jego mać...
Oryginał tego wpisu dostępny jest pod adresem Kupno spodni to spore wyzwanie
Autor: Paweł Goleń
Po co w bazach dostępne jest INFORMATION_SCHEMA? Wbrew rozpowszechnionym pogłoskom nie po to, by SQLi było łatwiejsze (rozpoznanie struktury bazy danych). Po prostu jest to część SQL-92.
Oryginał tego wpisu dostępny jest pod adresem [Po co INFORMATIONSCHEMA](https://archive.mroczna-zaloga.org/archives/1218-po-co-information_schema.html)_
Autor: Paweł Goleń
Dość ciekawa lektura: Dissecting the Tactics & Techniques of an Advanced Adversary (oraz RSA Incident Response Emerging Threat Profile: Shell_Crew).
Po pierwsze warto przeczytać rozdział “Intrusion Details”, bo jest to... piorunujące:
Dalsza część tego rozdziału (wrzucanie shelli) już nie jest taka ciekawa, choć można zastanowić się, dlaczego była możliwość zapisu plików (inaczej – czy musiała być), a także dlaczego integralność plików (i pojawianie się nowych) nie była monitorowana.
W dalszej części podobały mi się dwa podrozdziały rozdziału “Entrenchment Techniques”, konkretnie:
Ten patent z modyfikacją System.Web.dll podobał mi się szczególnie :)
Oryginał tego wpisu dostępny jest pod adresem Uczyć się na cudzych błędach
Autor: Paweł Goleń
Czasami przychodzi taka chwila, że trzeba podjąć decyzję o zmianie abonamentu. Jak podjąć decyzję jaki abonament wybrać? To proste, trzeba tylko:
Oryginał tego wpisu dostępny jest pod adresem Jak wybrać abonament
Autor: Paweł Goleń
Jestem, nic mi nie jest. Pewnie za jakiś czas napiszę coś konkretnego.
Oryginał tego wpisu dostępny jest pod adresem BIP, BIP, BIP
Autor: Paweł Goleń
Załóżmy, że mamy przechować jakiś sekret. Nie do końca chodzi nam o to, by był on przechowywany w sposób nieodwracalny, natomiast zdecydowanie chcemy mieć możliwość sprawdzenia, czy określona osoba ten sekret zna.
Tak, dokładnie o to chodzi również przy przechowywaniu haseł. Tu absolutnym standardem jest przechowywanie sekretów (haseł) w formie skrótu (hasha), który powinien być nie tylko nieodwracalny, ale również kosztowny do wyliczenia. Wszystko po to, by atak brute force był jak najbardziej kosztowny (obliczeniowo). Są jednak takie przypadki, w których przestrzeń możliwych wartości sekretu jest na tyle niewielka, że podejście oparte na wykorzystaniu hasha po prostu się nie sprawdza.
W takich przypadkach lepszym podejściem jest zaszyfrowanie sekretu i przechowywanie go w takiej postaci. Oczywiście szyfrowanie musi być wykonane z głową, bo inaczej skutki są takie: Anatomy of a password disaster – Adobe's giant-sized cryptographic blunder.
Jeśli szyfrowanie zostanie zrealizowane poprawnie, to atak na hasła sprowadzi się do ataku na wykorzystany szyfr. W praktyce oznacza to konieczność odgadnięcia klucza, który ma co najmniej 128 bitów. Powodzenia.
Ale jednocześnie właśnie tu jest problem – system by działać, musi mieć dostęp do tego klucza. Z pewnym prawdopodobieństwem należy więc założyć, że również atakujący będzie miał do niego dostęp (choć w przypadku wspomnianej już wpadki Adobe – klucza najwyraźniej nie udało się zdobyć).
Jaki stąd morał? Warto zastanowić się co chcemy chronić i jaka jest możliwa przestrzeń wartości tego sekretu. W pewnych sytuacjach bardziej bezpiecznym rozwiązaniem będzie wybranie szyfrowania i próba utrudnienia dostępu do klucza.
P.S. W zasadzie dokładnie to samo można osiągnąć przy pomocy tajnego pepper (uzupełniając jawny salt). Oczywiście tutaj należy z kolei zadbać o to, by pepper nie był łatwo dostępny dla atakującego.
P.S2. A przypomniało mi się to w związku z tym: Can hackers decrypt Target's PIN data? Przy okazji – warto zwrócić uwagę na sztuczki zastosowane po to, by uniknąć sytuacji, w której dwa różne PIN szyfrują się do tej samej wartości (wykorzystany jest 3DES w trybie ECB).
Oryginał tego wpisu dostępny jest pod adresem Dlaczego szyfrowanie jest (czasem) lepsze
Autor: Paweł Goleń
Wczoraj miałem okazję być na warsztacie/prezentacji Bezpieczeństwo danych w szwajcarskim banku – proces analizy ryzyka IT w UBS, który odbył się w ramach BAIT. Muszę przyznać, że wyszło to całkiem dobrze, Marcin dał radę w ciekawy sposób opowiedział o co w tym wszystkim chodzi. Ja się tam prawie nie odzywałem :)
Oczywiście trzeba pamiętać, że temat jest bardzo rozległy i w takim czasie nie można opowiedzieć o wszystkim. Podstawowe rzeczy jednak zostały poruszone. Podstawowe, czyli:
Jest też mały konkurs ;)
P.S. Tak na marginesie – ciekawe jest na przykład to, że taki podstawowy termin jak ryzyko wcale nie jest jednoznacznie zdefiniowane. Dwie osoby o różnym “pochodzeniu” (background zawodowy) używając pojęcia ryzyko mogą w rzeczywistości mówić o dwóch zupełnie innych rzeczach.
Oryginał tego wpisu dostępny jest pod adresem Warsztaty BAIT
Autor: Paweł Goleń
Dziś cofnijmy się mniej więcej o rok, konkretnie do tego wpisu: Jak zepsuć uwierzytelnienie w aplikacji mobilnej? A konkretnie do tego przypadku, w którym hasło (PIN) do aplikacji mobilnej było wykorzystywane do wygenerowania klucza używanego do szyfrowania danych przechowywanych lokalnie na urządzeniu. W opisywanym scenariuszu skutki takiego rozwiązania były tragiczne – kwestią sekund było odzyskanie kodu PIN potrzebnego do uwierzytelnienia się w aplikacji, oczywiście pod warunkiem, że ktoś wcześniej uzyskał dostęp do urządzenia ofiary.
Tym razem pokażę w jaki sposób zmodyfikować to rozwiązanie, by było odrobinę lepsze.