Paweł Goleń, blog

Taka krótka refleksja na temat usability. Wyjątkowo irytuje mnie sytuacja, gdy muszę podawać dane typu PESEL a później data urodzenia. Tak się składa, że data urodzenia jest zakodowana w numerze PESEL, więc wprowadzając najpierw swój numer PESEL już podaję datę urodzenia. Informacja zakodowana w numerze PESEL może i powinna być wykorzystana co najmniej do automatycznego wypełnienia daty urodzenia.

Oczywiście mówię tu o sytuacji, w której te dane muszę podać w trakcie testów jakiejś aplikacji. Nie podaję swoich danych (swojego numeru PESEL zresztą nie pamiętam), tylko wartości wygenerowane narzędziami typu generator numerów PESEL i wyjątkowo irytuje mnie późniejsze wpisywanie daty urodzenia i poprawianie płci. Zgoda, pewną wartością dodaną może być weryfikacja numeru PESEL na zasadzie sprawdzenia go z datą urodzenia oraz płcią (płeć jest również zakodowana w numerze PESEL), które użytkownik deklaruje przy wypełnianiu formularza, ale akurat w tym wypadku mówię o wygodzie użytkowania, a z tym bywa różnie. Może o spotkanych "potworkach" napiszę kiedy indziej :)

W drugim wyzwaniu na bootcamp została wykorzystana serializacja danych do przechowywania stanu sesji (patrz pierwsza część wyjaśnienia do zadania). Przykłady, które prezentuje mają przedstawiać typowe problemy z bezpieczeństwem aplikacji internetowych, a nie z konkretnym środowiskiem/językiem programowania, ten przykład jest praktyczną demonstracją problemu określanego jako CWE-642: External Control of Critical State Data, o czym już kilka razy wspominałem. Warto jednak zatrzymać się na chwilę przy funkcjach serialize/unserialize w PHP.

Nadrabiający zaległości w przykładach z bootcamp Krzysiek Kotowicz zaproponował bardzo ciekawe rozwiązanie zadania polegającego na wstawieniu skryptu z zewnętrznej strony, a właściwie interesujący jego wariant.

Przede wszystkim odsyłam do wpisu Do więzienia za korzystanie z sieci TOR??! Jeśli rzeczywiście poseł ma takie pomysły, to strach się bać:

Poseł zwrócił się także z pytaniem o możliwość, w przypadku braku technicznych możliwości wykrywania sprawców przestępstw pedofilskich popełnionych za pomocą sieci TOR oraz z uwagi na szczególne dobro jakie zamierza się chronić (dobro dzieci), dokonania penalizacji używania oprogramowania umożliwiającego korzystanie z sieci TOR. (...)

Moja spiskowa teoria dziejów zaczyna być nie tak bardzo oderwana od rzeczywistości...

Jakieś dodatkowe pomysły co by tu można jeszcze poddać penalizacji? Oczywiście z uwagi na szczególne dobro jakie zamierza się chronić? Przykłady innych przypadków szczególnego dobra również mile widziane.

W ostatnim czasie pojawiły się dwie informacje dotyczące ataków mechanizm BitLocker. Pierwsza z nich to to w zasadzie informacja prasowa Passware Software Cracks BitLocker Encryption Open. Metoda ta opiera się na odzyskaniu klucza wykorzystywanego do szyfrowania danych z pamięci systemu. Jak do pamięci uzyskać dostęp, to zupełnie oddzielna (i ciekawa) kwestia. Nie jest to bynajmniej technika nowatorska, wystarczy wspomnieć o pracy/badaniu Lest We Remember: Cold Boot Attacks on Encryption Keys.

Druga wiadomość to praca Attacking the BitLocker Boot Process, która doczekała się na przykład takiego "streszczenia": Złamano szyfrowanie w Windows, albo: BitLocker złamany. Szkoda tylko, że w samym dokumencie znajduje się następujący fragment:

(...) We show that, under certain assumptions, a dedicated attacker can circumvent the protection and break confidentiality with limited effort. Our attacks neither exploit vulnerabilities in the encryption itself nor do they directly attack the TPM. They rather exploit sequences of actions that Trusted Computing fails to prevent, demonstrating limitations of the technology.

Na zakończenie odeślę do wpisu Windows BitLocker Claims poświęconemu obu przypadkom/scenariuszom ataków na mechanizm BitLocker. Po prostu są scenariusze, w których (nie tylko) BitLocker sobie nie radzi. Wątpliwości? Evil Maid goes after TrueCrypt!