Ograniczenie liczby żądań

Android chroni dane użytkownika, w tym przechowywane w zaszyfrowanym magazynie dane logowania i klucze Keystore powiązane z uwierzytelnianiem, za pomocą skonfigurowanych przez użytkownika czynników wiedzy o ekranie blokady (LSKF) , takich jak kody PIN, wzory i hasła. LSKF to zwykle wartości o niskiej entropii, takie jak 4- lub 6-cyfrowe kody PIN, dlatego wymagana jest ochrona przed atakami brute force.

Android używa ograniczników szybkości w zaufanym środowisku wykonawczym (TEE) lub bezpiecznym elemencie (SE), aby spowolnić, a po wystarczającej liczbie prób zablokować hakerów przeprowadzających ataki brute force na LSKF. Dokument CDD 9.11 określa minimalne wymagania i zalecenia dotyczące ograniczników szybkości LSKF. Android 16 QPR2 i nowsze wersje implementują znacznie silniejsze zasady ograniczania szybkości niż starsze wersje Androida. Więcej informacji znajdziesz w artykule Silniejsze domyślne zasady ograniczania szybkości w Androidzie 16 QPR2 i nowszych wersjach.

Android 17 i nowsze wersje używają silniejszego domyślnego ograniczania szybkości na ekranie blokady niż starsze wersje. W rzadkich przypadkach użytkownicy mogą doświadczyć długich limitów czasu na ekranie blokady, dlatego Android 17 i nowsze wersje zapewniają ulepszone opinie użytkowników na ekranie blokady.

  • Ulepszone formatowanie czasu: ekran blokady wyświetla limity czasu trwające minutę lub dłużej używając większych jednostek czasu, aby poprawić czytelność, np. Spróbuj ponownie za 30 minut zamiast Spróbuj ponownie za 1800 sekund.
  • Krótki link do odzyskiwania: ekran blokady wyświetla krótki link (domyślnie g.co/android/unlock), który pomaga użytkownikom znaleźć opcje odzyskiwania na innym urządzeniu. Ten link można skonfigurować za pomocą zasobu config_lockscreenLockoutShortlink.
  • Opinie o duplikatach prób: na urządzeniach z implementacją Weaver system wyświetla unikalny komunikat, gdy zostanie wprowadzona duplikat nieprawidłowej próby. Ta konkretna opinia jest niedostępna na urządzeniach, które korzystają tylko z Gatekeepera, ponieważ nie udostępniają one oddzielnych kodów odpowiedzi na nieprawidłowe próby i inne błędy weryfikacji.
  • Spójne zarządzanie wprowadzaniem danych logowania: ekran blokady wyłącza klawiaturę do wprowadzania kodu PIN, jeśli urządzenie używa kodu PIN jako danych logowania, podobnie jak w przypadku hasła i wzoru.

Metoda LockPatternUtils#getLockoutAttemptDeadline(int) została zmieniona na LockPatternUtils#getLockoutEndTime(int) i podaje czas zakończenia blokady z pamięci podręcznej zarządzanej przez system. Ta aktualizacja rozwiązuje problem, w którym były one buforowane tylko na instancję LockPatternUtils, co powodowało błędne wyświetlanie braku aktywnego limitu czasu, jeśli został on wywołany za pomocą innej instancji. Deweloperzy systemowych promptów dotyczących danych logowania, takich jak ekran blokady i ustawienia, muszą je zaktualizować, aby przed zezwoleniem na kolejne próby sprawdzić, czy istnieją limity czasu.

Odblokowywanie chronionych danych użytkownika za pomocą LSKF

LockSettingsService zarządza przechowywaniem i weryfikowaniem LSKF. Użytkownik może mieć w danym momencie tylko 1 aktywny LSKF. Przypisanie nowego LSKF unieważnia poprzedni i rozpoczyna zasady ograniczania szybkości od początku.

Główny ogranicznik szybkości w TEE lub SE, czyli Gatekeeper lub Weaver, wymusza ograniczanie szybkości dla aktywnego LSKF. Gdy implementacja jest dostępna, LockSettingsService preferuje Weavera.

Chronione dane użytkownika są odblokowywane tylko wtedy, gdy do głównego ogranicznika szybkości zostanie podany prawidłowy LSKF. Jeśli LSKF jest nieprawidłowy, ogranicznik szybkości zwiększa licznik błędów i wymusza limit czasu po określonej liczbie błędów. Podczas limitu czasu odrzuca wszystkie próby i podaje pozostały limit czasu.

Silniejsze domyślne zasady ograniczania szybkości w Androidzie 16 QPR2 i nowszych wersjach

Dokument CDD 9.11 wymaga ograniczania szybkości LSKF w Androidzie 6 i nowszych wersjach. W przeszłości wymagane zasady ograniczania szybkości były dość łagodne. Na przykład implementacja spełniająca minimalne wymagania Androida 16 pozwala na maksymalnie 10 prób w pierwszej minucie, 20 w 6 minutach, 50 w 25 minutach, 110 w 24 godzinach i 1800 prób w 5 latach.

Chociaż te zasady są dość bezpieczne w przypadku LSKF wybranych losowo, w praktyce użytkownicy nie wybierają LSKF losowo. Niektóre LSKF występują znacznie częściej niż inne. Hakerzy mogą osiągnąć znaczną skuteczność, próbując LSKF w kolejności malejącej częstotliwości.

Na przykład w badaniu This PIN Can Be Easily Guessed stwierdzono, że skuteczność odgadywania rzeczywistych kodów PIN po 100 próbach wynosi 16,2%, a w przypadku wzorów – 35,5%. Hakerzy znający informacje o użytkowniku, takie jak data urodzenia, mogą osiągnąć jeszcze wyższą skuteczność.

Dlatego Android 16 QPR2 i nowsze wersje zapewniają silniejsze domyślne zasady ograniczania szybkości LSKF. Te zasady pozwalają na maksymalnie 6 prób w pierwszej minucie, 7 w 6 minutach, 8 w 25 minutach, 12 w 24 godzinach i 19 w 5 latach. Po 20 nieprawidłowych próbach nie można już próbować. Pełny harmonogram limitów czasu znajdziesz w tabeli poniżej. W przyszłych wersjach Androida może się on zmienić.

Liczba nieprawidłowych prób Limit czasu po nieprawidłowej próbie
0 Nie dotyczy
1–4 0 sekund
5 1 minuta
6 5 minut
7 15 minut
8 30 minut
9 90 minut
10 4 godziny
11 12 godzin
12 36 godzin
13 4 dni
14 13 dni
15 41 dni
16 123 dni
17 1 rok
18 3 lata
19 9 lat
20+ Nie można już próbować

Zaktualizowane ograniczniki szybkości

Android 16 QPR2 i nowsze wersje zawierają zaktualizowane implementacje Gatekeepera i Weavera, które wymuszają zasady ograniczania szybkości w tabeli.

Ogranicznik szybkości oprogramowania

Android 16 QPR2 i nowsze wersje zawierają opcjonalny ogranicznik szybkości, SoftwareRateLimiter. Jest on zaimplementowany na serwerze systemowym i umożliwia urządzeniom stosowanie silniejszych zasad ograniczania szybkości, gdy nie można zaktualizować TEE ani SE.

Skonfiguruj SoftwareRateLimiter w trybie wymuszania za pomocą wartości konfiguracji config_softwareLskfRateLimiterEnforcing. W trybie wymuszania SoftwareRateLimiter stosuje swoje zasady ograniczania szybkości równocześnie z głównym ogranicznikiem szybkości. W przypadku danej liczby nieprawidłowych prób limit czasu jest dłuższy niż wymagany przez główny ogranicznik szybkości i SoftwareRateLimiter. W trybie niewymuszania SoftwareRateLimiter przekazuje wszystkie żądania weryfikacji do głównego ogranicznika szybkości bez stosowania dodatkowych zasad ograniczania szybkości.

Wykrywanie duplikatów prób

Aby zwiększyć wygodę użytkowania i umożliwić stosowanie silniejszych zasad ograniczania szybkości, Android 16 QPR2 i nowsze wersje obsługują wykrywanie duplikatów prób. Gdy ta funkcja jest włączona, użytkownicy nie są karani za wielokrotne wprowadzanie tego samego nieprawidłowego LSKF.

Prawidłowi użytkownicy czasami wielokrotnie wprowadzają ten sam nieprawidłowy LSKF. Jeśli jest to liczone jako wiele prób, powoduje to niepotrzebne limity czasu. Sprawni hakerzy nie próbują danego LSKF więcej niż raz. Zasady, które nie uwzględniają duplikatów prób, zwiększają wygodę wprowadzania LSKF przez prawidłowych użytkowników, nie ułatwiając jednocześnie sprawnym hakerom odgadywania LSKF, co pozwala na egzekwowanie silniejszych zasad ograniczania szybkości. Prawidłowi użytkownicy rzadziej napotykają limit czasu, ponieważ muszą wprowadzić 5 unikalnych nieprawidłowych prób zamiast 5 nieprawidłowych prób, w tym duplikatów.

Na urządzeniach z Androidem 16 QPR2 i nowszymi wersjami, implementacją Weavera i SoftwareRateLimiter skonfigurowanym w trybie wymuszania duplikaty prób są wykrywane i odrzucane przed przekazaniem do Weavera. Takie odrzucenia nie zwiększają liczby nieprawidłowych prób. W pamięci śledzonych jest maksymalnie 5 unikalnych nieprawidłowych prób. Jeśli tracker jest pełny, najstarsza próba jest odrzucana, aby zwolnić miejsce. Wszystkie śledzone próby są odrzucane 5 minut po ostatniej nieśledzonej nieprawidłowej próbie.

Gatekeeper nie rozróżnia nieprawidłowych prób od innych błędów weryfikacji, dlatego SoftwareRateLimiter nie obsługuje wykrywania duplikatów prób, gdy Gatekeeper jest głównym ogranicznikiem szybkości.

Osoby implementujące Weavera mogą zdecydować się na obsługę wykrywania duplikatów prób w implementacji Weavera.