Paweł Goleń, blog

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.

Dzisiaj komentarz do tego tematu: Okradli klientów PKO BP, przez internet, bez znajomości kodów jednorazowych. Właściwie do pewnego stopnia mój komentarz jest tutaj, ale tematowi warto poświęcić kilka słów więcej.

Zachęcam do posłuchania Risky Business #305 -- Secure, anonymous IM not a pipe dream. Konkretnie chodzi mi o rozmowę dotyczącą bezpiecznego IM.

W czym jest problem, czy szyfrowanie nie wystarczy? Okazuje się, że bardzo często - nie. Trzeba pamiętać, że komunikacja ma wiele "cech":

• kto z kim,
• kiedy,
• jak często,
• jak długo,
• jaka ilość danych została wymieniona,
• co było w tych danych,

Warto również zwrócić uwagę na to, że zmiana typowych wzorców komunikacji również sama w sobie jest informacją.

Szyfrowanie w miarę skutecznie ukrywa tylko ten ostatni element. Na podstawie pozostałych cech nadal można wyciągnąć bardzo interesujące wnioski. Zwłaszcza, jeśli są jakieś dodatkowe dane, które można korelować. Można przypomnieć tutaj choćby przykład z "odgadywaniem" na co ktoś patrzy w Google Maps: I can still see your actions on Google Maps over SSL. To wszystko powoduje, że Pidgin z OTR nie zawsze wystarczy.

P.S. I w ramach ciekawostki: Operacja Fortitude.

(...) Utworzono grupę radiostacji które "porozumiewały" się wzajemnie nadając komunikaty o treści, jakich można się spodziewać w czasie formowania dużej grupy armii. (...)

Zdecydowanie warto przeczytać: The Security Impact of HTTP Caching Headers. Temat nie jest nowy, jednak wciąż sytuacja w tym zakresie wygląda słabo. Bardzo często można natknąć się na dwie skrajne sytuacje:

• możliwe jest użycie cache dla "prywatnych" danych,
• cache nie jest używany nawet dla statycznych treści,

Obie skrajności są złe, w pierwszym przypadku pojawia się problem z poufnością informacji. Treść, która w teorii powinna być dostępna tylko dla konkretnego użytkownika, może zostać zapisana w wielu, bliżej nieokreślonych miejscach. Drugi scenariusz z kolei jest uciążliwy pod względem wykorzystania zasobów - wielokrotne pobieranie tych samych treści kosztuje nie tylko przepustowość, ale również czas.

Dla zwykłego użytkownika sam fakt wielokrotnego pobrania tych samych danych może być nieistotny. Istotny za to będzie wydłużony czas ładowania strony - to coś, co taki zwykły użytkownik jest w stanie zauważyć.

Na koniec - przypominam, że jakiś czas temu przygotowałem stronę, na której z tymi nagłówkami można sobie poeksperymentować.

Do poczytania: A roster of TLS cipher suites weaknesses. Ciekawy zbiór aktualnych informacji odnośnie tego co obecnie w TLS jest, a co nie jest bezpieczne.