Paweł Goleń, blog

Dziś odbyłem długą i, w pewnym stopniu, interesującą dyskusję z osobą, która chciała namówić mnie na dodatkowe ubezpieczenie NW. Podkreślam – dodatkowe, ubezpieczenie o takich samych warunkach mam w ramach ubezpieczenia grupowego.

Argumentacja osoby namawiającej była taka, że przecież lepiej mieć odszkodowanie z dwóch źródeł, niż z jednego. Owszem, ale:

  • koszt tego dodatkowego ubezpieczenia to 300 PLN rocznie;
  • maksymalna wypłata to 60 000 PLN;
  • liczba zdarzeń objętych ubezpieczeniem w ciągu mojego życia: ZERO.

Tak, wypadki chodzą po ludziach. Ale jednak styl życia konkretnej osoby wpływa na prawdopodobieństwo zaistnienia takiego zdarzenia. Fakt, nie wszystko jest pod naszą kontrolą. Gdybym nie miał już takiego ubezpieczenia, rozważyłbym jego zakup. W pewnych szczególnych przypadkach sensowne jest również nabycie dodatkowego ubezpieczenia na określony czas (np. na czas podróży, czy wyjazdu na narty). Choćby dlatego, że planowane aktywności mogą nie być objęte przez “standardowe” ubezpieczenie.

Najciekawszy element tej rozmowy – osoba sprzedająca stwierdziła, że skoro do tej pory takie zdarzenie nie miało miejsca, to jego prawdopodobieństwo rośnie. Tak, jasne. A prawdopodobieństwo wyrzucenia orła w drugiej próbie rośnie jeśli w pierwszej wypadała reszka.

Oryginał tego wpisu dostępny jest pod adresem Jak nie kupiłem (dodatkowego) ubezpieczenia

Autor: Paweł Goleń

Tak, chodzi o Android 4.4. Nie, nie chodzi o jego zachowanie na mocnych telefonach. Mam stary telefon Live with Walkman (coconut). Zainstalowałem na nim ostatnio KitKat z LegacyXperia i muszę przyznać, że telefon daje radę. Lepiej, niż na CyanogenMod z linii 10.1, której używałem wcześniej.

Nie, nie używam tego starego telefonu regularnie, właściwie służy mi podczas wypraw rowerowych. Choć już dawno nie zaliczyłem bliskiego spotkania z ziemią, takie zdarzenie jest zawsze prawdopodobne i w przypadku jego zaistnienia wolę mieć w plecaku coś mniejszego i mniej wartościowego :)

Oryginał tego wpisu dostępny jest pod adresem KitKat jednak szybki jest

Autor: Paweł Goleń

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:

  • Nieaktualne oprogramowanie – CVE-2010-2861 (APSB10-18) wykorzystany w 2013 roku(!);
  • Hasło przechowywane w sposób pozwalający na atak z wykorzystaniem Rainbow Table (brak salt);
  • Prawdopodobnie wykorzystane (relatywnie) słabe hasło – w końcu znalazło się w tablicy.

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:

  • Registering DLLs with Internet Information Services (IIS);
  • Modifying the 'System.Web.dll' file.

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:

  1. ustalić jakich danych potrzeba (czas rozmów, do jakich sieci, ilość SMS);
  2. zebrać dane do analizy (stare faktury);
  3. przeanalizować dane (wartość średnia, odchylenie standardowe, 90%25 przedział pewności);
  4. w oparciu o zebrane dane przygotować symulację Monte Carlo dla rozważanych abonamentów;
  5. na podstawie wyników symulacji wybrać ten abonament, który od samego początku wydawał się najlepszy :)

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ń