Skip to content Skip to footer

Czy hasła mają jeszcze sens?

Urządzenie mobilne przechowują bardzo duże ilości informacji dotyczących swoich właścicieli. Producenci smartfonów, wraz z twórcami systemów operacyjnych dostarczają coraz bardziej zaawansowanych mechanizmów ochrony danych przechowywanych na urządzeniu. Normą staje się wykorzystanie dedykowanych układów odpowiedzialnych za bezpieczne przetwarzanie wrażliwych informacji, czy też dokonywanie operacji kryptograficznych. Użytkownicy w wyniku tego rozwoju dostają wygodniejsze metody uwierzytelniania, co zgodnie z obietnicami producentów sprzętu ma w niewielkim stopniu wpływać na bezpieczeństwo użytkowników. Czy w związku z powyższym stosowanie hasła dostępowego ma jeszcze sens? Spróbujemy odpowiedzieć na to pytanie analizując dane aplikacji dla systemu Android.

Pamięć wewnętrzna aplikacji

Aplikacje pracujące pod kontrolą systemu operacyjnego Android posiadają kilka możliwość przechowywania danych. Każda z tych możliwości różni się między sobą ilością miejsca dostępnego dla aplikacji, jak i poziomem uprawnień niezbędnym do uzyskania do nich dostępu. Rozróżnia się cztery podstawowe metody przechowywania danych:

  • Internal storage (pamięć wewnętrzna), która pozwala na przechowywanie prywatnych danych aplikacji w systemie plików urządzenia. Dostęp do tych danych wymaga uprawnień użytkownika root.
  • External storage (pamięć zewnętrzna), pozwalają na przechowywanie dużej ilości danych we współdzielonej przestrzeni pamięci. Wykorzystywana przez aplikacja do przechowania np. zdjęć, kopii zapasowych itp. pamięć zewnętrzna powinna przechowywać jedynie dane zewnętrzne, których wyciek nie spowoduje zagrożenia dla aplikacji.
  • Shared preferences (współdzielone ustawienia), pozwalająca na przechowywanie prywatnych danych aplikacji w postaci klucz-wartość.
  • Bazy danych, które pozwalają na przechowywanie prywatnych danych aplikacji w postaci bazy danych o ustalonej strukturze. System operacyjny Android wykorzystuje bazy danych SQLite.

W niniejszym artykule zostały przeanalizowane jedynie prywatne dane aplikacji – wydzielona strefa, w której aplikacja może przechowywać swoje dane. Tylko te, które nie są dostępne z poziomu innych aplikacji. Z tego powodu, w celu dokonania analizy konieczne jest uzyskanie uprawnień root na urządzeniu. W przypadku standardowych urządzeń jest to wystarczający poziom ochrony uniemożliwiający dokonanie ataku przez osoby o niskich kwalifikacjach i zasobach.

Szyfrowanie bazy danych

Począwszy od systemu Android 6.0 deweloperzy uzyskali potężne narzędzie, jakim jest Android Keystore. Pozwala on na realizację operacji kryptograficznych, składowanie kluczy szyfrujących itp, a to wszystko w sposób powiązany z danym urządzeniem. W przypadku zabezpieczeń softwareowych oznacza to konieczność przeniesienia dokładnej kopii pamięci, co pozwala na odtworzenie danych zapisanych w urządzeniu. W przypadku zabezpieczeń hardware’owych takie odtworzenie nie jest możliwe bez ominięcia zabezpieczeń dedykowanego modułu.

Pomimo swoich niewątpliwych zalet, Keystore nie chroni danych użytkownika w sytuacji, w której zostanie pozyskany jego materiał uwierzytelniający – odcisk palca, pin, wzór blokady etc. Możliwe jest także wystąpienie w pewnym czasie luk w zabezpieczeniach, tylnych furtek etc., które wyeliminują korzyść wynikająca z zastosowania tego mechanizmu. W przypadku zabezpieczania danych szczególnie wrażliwych warto zatem zastosować dodatkowy mechanizm, który utrudni przeciwnikowi przejęcie chronionej informacji. Dla danych składowanych w bazie może to zostać zrealizowane np. poprzez wykorzystanie hybrydowego szyfrowania. Struktura bazy danych może być szyfrowana z wykorzystaniem mechanizmu Keystore (baza SQLCipher), a dodatkowo jej zawartość może być zabezpieczona poprzez zastosowanie dodatkowego sekretu. W takim przypadku siła dodatkowego zabezpieczenia będzie równa wartości siły (entropii) wykorzystanego przez użytkownika sekretu. Poniżej przedstawione zostały poziomy entropii dla poszczególnych rodzajów haseł:

Na podstawie obliczonej entropii istnieje możliwość skategoryzowania hasła w podstawowe grupy odporności

Entropia:

  • mniejsza niż 28 bitów – hasło bardzo słabe, ochroni jedynie przed członkami rodziny
  • na poziomie 28-35 bitów – hasło słabe, wystarczające do ochrony przed większością atakujących
  • na poziomie 36-59 bitów- hasło umiarkowane, wystarczająco bezpieczne do ochrony sieci lub tajemnic firmowych
  • 60-127 bitów- hasło silne, wystarczające do ochrony informacji poufnych
  • powyżej 128 bitów – hasło bardzo silne, ochrona przed każdym rodzajem ataku

Istotny aspektem jest zatem dokonanie kategoryzacji hasła na etapie jego ustanawiania. Pozwala to użytkownikowi na dobór hasła do oczekiwanego poziomu ochrony. Należy zauważyć, iż w przypadku prawidłowej implementacji, potencjalny atakujący nie posiada informacji o rodzaju wykorzystywanych znaków ani długości hasła.Ppowoduje to dodatkowe wydłużenie czasu potrzebnego do wykonania ataku. Przykładowo, aby zaatakować 6 znakowe hasło alfanumeryczne, oczekuje się siły na poziomie

Dla instancji Amazon EC2 p3.16xlarge wydajność obliczenia hashy dla PBKDF2 (4095 iteracji) to 6,5143 MH/s. Koszt dzierżawy to od 8,39 do 24,48 USD za godzinę pracy. Dla analizowanego hasła 6-znakowego należałoby zatem ponieść następujący koszt ataku:

Gdzie 250000 oznacza zalecaną liczbę iteracji PBKDF2. Entropia jest na poziomie 35,75 bitów, koszt godziny pracy analizowany jest w trzech przedstawionych cennikach. Dla takich parametrów koszt przeprowadzenia ataku wynosi zatem minimum 14,3*1012 USD, czyli 14,3 biliona USD. Czas wykonania takiego ataku to 1,7 biliona godzin.

Werdykt

Stosowanie mechanizmu niezależnego od systemu operacyjnego może w znaczący sposób wydłużyć czas potrzebny od wykonania skutecznego ataku. Nawet w przypadku uzyskania dostępu do pełnej kopii systemu oraz ominięcia narzucanych przez Keystore ograniczeń, atakujący musi wykonać atak słownikowy lub pełne przeszukanie przestrzeni haseł w celu wyznaczenia właściwej kombinacji. Przy odpowiednio dużej sile hasła atak taki jest niezwykle kosztowny i czasochłonny. Co warte podkreślenia – konieczny do wykonania w każdym przypadku przejęcia danych. Zastosowanie jedynie mechanizmu systemowego pozwalałoby ograniczyć zasoby niezbędne do ataku – wystarczającym byłoby przełamanie mechanizmu wykorzystywanego w serii urządzeń.