Bezpieczne uwierzytelnianie użytkowników

Aby chronić system uwierzytelniania na Androidzie, rozważ odejście od modelu opartego na hasłach, zwłaszcza w przypadku kont, które zawierają dane wrażliwe, takich jak konta bankowe i e-mail użytkowników. Pamiętaj, że niektóre aplikacje instalowane przez użytkowników mogą mieć nieuczciwe intencje i próbować wyłudzić od nich informacje.

Nie zakładaj też, że z urządzenia będą korzystać tylko autoryzowani użytkownicy. Kradzieże telefonów to powszechny problem, a przestępcy atakują odblokowane urządzenia, aby bezpośrednio czerpać zyski z danych użytkowników lub aplikacji finansowych. Zalecamy, aby wszystkie aplikacje, które przetwarzają dane wrażliwe, miały rozsądny limit czasu uwierzytelniania (15 minut?) z weryfikacją biometryczną i wymagały dodatkowego uwierzytelniania przed wykonaniem działań związanych z danymi wrażliwymi, takich jak przelewy pieniężne.

Okno uwierzytelniania biometrycznego

Biblioteka Biometrics udostępnia zestaw funkcji do wyświetlania prośby o uwierzytelnianie biometryczne, np. rozpoznawanie twarzy lub odcisków palców. Monity biometryczne można jednak skonfigurować tak, aby w razie potrzeby przełączały się na LSKF, co wiąże się z znanym ryzykiem podglądania. W przypadku aplikacji wymagających ochrony danych zalecamy, aby w razie niepowodzenia uwierzytelniania biometrycznego nie przechodzić do uwierzytelniania za pomocą kodu PIN. Po wyczerpaniu prób uwierzytelniania biometrycznego użytkownicy mogą poczekać, ponownie zalogować się za pomocą hasła lub zresetować konta. Resetowanie konta powinno wymagać czynników, które nie są łatwo dostępne na urządzeniu (najlepsze praktyki poniżej).

Jak to pomaga ograniczyć oszustwa i kradzieże telefonów

Jednym z przypadków użycia, który może pomóc w zapobieganiu oszustwom, jest żądanie uwierzytelniania biometrycznego w aplikacji przed transakcją. Gdy użytkownicy chcą dokonać transakcji finansowej, wyświetla się okno dialogowe z prośbą o dane biometryczne, aby potwierdzić, że transakcję wykonuje właściwy użytkownik. Ta sprawdzona metoda chroni przed kradzieżą urządzenia przez osobę atakującą, niezależnie od tego, czy zna ona klucz LSKF. Musi ona bowiem udowodnić, że jest właścicielem urządzenia.

Aby zwiększyć poziom bezpieczeństwa, zalecamy deweloperom aplikacji, aby w przypadku transakcji bankowych i finansowych wymagali uwierzytelniania biometrycznego klasy 3 i korzystali z CryptoObject.

Implementacja

  1. Upewnij się, że biblioteka androidx.biometric jest uwzględniona.
  2. Umieść okno logowania biometrycznego w aktywności lub fragmencie, który zawiera logikę, w przypadku której chcesz, aby użytkownik został uwierzytelniony.

Kotlin

private var executor: Executor? = null
private var biometricPrompt: BiometricPrompt? = null
private var promptInfo: BiometricPrompt.PromptInfo? = null

fun onCreate(savedInstanceState: Bundle?) {
  super.onCreate(savedInstanceState)
  setContentView(R.layout.activity_login)
  executor = ContextCompat.getMainExecutor(this)
  biometricPrompt = BiometricPrompt(this@MainActivity,
    executor, object : AuthenticationCallback() {
      fun onAuthenticationError(
        errorCode: Int,
        @NonNull errString: CharSequence
      ) {
        super.onAuthenticationError(errorCode, errString)
        Toast.makeText(
          getApplicationContext(),
          "Authentication error: $errString", Toast.LENGTH_SHORT
        )
          .show()
      }

      fun onAuthenticationSucceeded(
        @NonNull result: BiometricPrompt.AuthenticationResult?
      ) {
        super.onAuthenticationSucceeded(result)
        Toast.makeText(
          getApplicationContext(),
          "Authentication succeeded!", Toast.LENGTH_SHORT
        ).show()
      }

      fun onAuthenticationFailed() {
        super.onAuthenticationFailed()
        Toast.makeText(
          getApplicationContext(), "Authentication failed",
          Toast.LENGTH_SHORT
        )
          .show()
      }
    })
  promptInfo = Builder()
    .setTitle("Biometric login for my app")
    .setSubtitle("Log in using your biometric credential")
    .setNegativeButtonText("Use account password")
    .build()

  // Prompt appears when user clicks "Log in".
  // Consider integrating with the keystore to unlock cryptographic operations,
  // if needed by your app.
  val biometricLoginButton: Button = findViewById(R.id.biometric_login)
  biometricLoginButton.setOnClickListener { view ->
    biometricPrompt.authenticate(
      promptInfo
    )
  }
}

Java

private Executor executor;
private BiometricPrompt biometricPrompt;
private BiometricPrompt.PromptInfo promptInfo;

@Override
protected void onCreate(Bundle savedInstanceState) {
    super.onCreate(savedInstanceState);
    setContentView(R.layout.activity_login);
    executor = ContextCompat.getMainExecutor(this);
    biometricPrompt = new BiometricPrompt(MainActivity.this,
            executor, new BiometricPrompt.AuthenticationCallback() {
        @Override
        public void onAuthenticationError(int errorCode,
                @NonNull CharSequence errString) {
            super.onAuthenticationError(errorCode, errString);
            Toast.makeText(getApplicationContext(),
                "Authentication error: " + errString, Toast.LENGTH_SHORT)
                .show();
        }

        @Override
        public void onAuthenticationSucceeded(
                @NonNull BiometricPrompt.AuthenticationResult result) {
            super.onAuthenticationSucceeded(result);
            Toast.makeText(getApplicationContext(),
                "Authentication succeeded!", Toast.LENGTH_SHORT).show();
        }

        @Override
        public void onAuthenticationFailed() {
            super.onAuthenticationFailed();
            Toast.makeText(getApplicationContext(), "Authentication failed",
                Toast.LENGTH_SHORT)
                .show();
        }
    });

    promptInfo = new BiometricPrompt.PromptInfo.Builder()
            .setTitle("Biometric login for my app")
            .setSubtitle("Log in using your biometric credential")
            .setNegativeButtonText("Use account password")
            .build();

    // Prompt appears when the user clicks "Log in".
    // Consider integrating with the keystore to unlock cryptographic operations,
    // if needed by your app.
    Button biometricLoginButton = findViewById(R.id.biometric_login);
    biometricLoginButton.setOnClickListener(view -> {
            biometricPrompt.authenticate(promptInfo);
    });
}

Sprawdzone metody

Aby dowiedzieć się więcej o biometrii, zacznij od samouczka.

W zależności od przypadków użycia możesz wdrożyć okno z wyraźnym działaniem użytkownika lub bez niego. Aby uniknąć oszustw, zalecamy dodanie okna dialogowego z dane biometryczne, które wymaga wyraźnej interakcji użytkownika w przypadku każdej transakcji. Rozumiemy, że dodanie uwierzytelniania może utrudnić korzystanie z usługi, ale ze względu na charakter informacji przetwarzanych w transakcji bankowej i fakt, że uwierzytelnianie biometryczne jest wygodniejsze niż inne metody uwierzytelniania, uważamy, że dodanie tego poziomu nawigacji jest konieczne.

Więcej informacji o uwierzytelnianiu biometrycznym

Klucze dostępu

Klucze dostępu to bezpieczniejsza i łatwiejsza w obsłudze alternatywa dla haseł. Klucze dostępu wykorzystują kryptografię klucza publicznego, aby umożliwić użytkownikom logowanie się w aplikacjach i witrynach za pomocą mechanizmu blokady ekranu urządzenia, takiego jak rozpoznawanie odcisku palca lub twarzy. Dzięki temu użytkownik nie musi pamiętać haseł ani nimi zarządzać, a bezpieczeństwo jest znacznie większe.

Klucze dostępu mogą spełniać wymagania uwierzytelniania wielopoziomowego w jednym kroku, zastępując hasło i kody OTP, aby zapewnić solidną ochronę przed atakami phishingowymi i uniknąć problemów z obsługą użytkowników związanych z jednorazowymi hasłami opartymi na SMS-ach lub aplikacjach. Klucze dostępu są standardowe, więc jedna implementacja umożliwia korzystanie z funkcji logowania bez hasła na wszystkich urządzeniach, przeglądarkach i systemach operacyjnych użytkowników.

Na Androidzie klucze dostępu są obsługiwane za pomocą biblioteki Credential Manager Jetpack, która ujednolica główne metody uwierzytelniania, w tym klucze dostępu, hasła i logowanie federacyjne (np. Zaloguj się przez Google).

Jak to pomaga ograniczyć oszustwa

Klucze dostępu chronią przed atakami phishingowymi, ponieważ działają tylko w zarejestrowanych aplikacjach i witrynach.

Klucz dostępu to przede wszystkim kryptograficzny klucz prywatny. Zwykle ten klucz prywatny znajduje się tylko na Twoich urządzeniach, takich jak laptopy czy telefony komórkowe, i jest synchronizowany między nimi przez dostawców danych logowania (znanych też jako menedżerowie haseł), np. Menedżera haseł Google. Gdy tworzony jest klucz dostępu, usługa online zapisuje tylko odpowiedni klucz publiczny. Podczas logowania usługa używa klucza prywatnego do podpisania wyzwania z klucza publicznego. Może to nastąpić tylko na jednym z Twoich urządzeń. Dodatkowo, aby to się stało, musisz odblokować urządzenie lub magazyn danych logowania, co zapobiega nieautoryzowanym logowaniom (np. z ukradzionego telefonu).

Aby zapobiec nieautoryzowanemu dostępowi w przypadku kradzieży odblokowanego urządzenia, klucze dostępu muszą być powiązane z rozsądnym czasem oczekiwania na uwierzytelnienie. Osoba, która ukradnie urządzenie, nie powinna mieć możliwości korzystania z aplikacji tylko dlatego, że poprzedni użytkownik był zalogowany. Zamiast tego dane logowania powinny wygasać w regularnych odstępach czasu (np. co 15 minut), a użytkownicy powinni być zobowiązani do potwierdzania swojej tożsamości przez ponowne uwierzytelnianie za pomocą blokady ekranu.

Jeśli Twój telefon zostanie skradziony, klucze dostępu zapewnią Ci ochronę, ponieważ złodzieje nie będą mogli ukraść Twoich haseł, aby używać ich na innych urządzeniach – klucze dostępu są powiązane z konkretnym urządzeniem. Jeśli korzystasz z Menedżera haseł Google i Twój telefon zostanie skradziony, możesz zalogować się na konto Google na innym urządzeniu (np. komputerze) i zdalnie wylogować się z ukradzionego telefonu. Sprawi to, że Menedżer haseł Google na skradzionym telefonie, w tym zapisane klucze dostępu, będzie bezużyteczny.

W najgorszym przypadku, jeśli skradzionego urządzenia nie uda się odzyskać, klucze dostępu zostaną zsynchronizowane z nowym urządzeniem przez dostawcę danych logowania, który je utworzył i zsynchronizował. Użytkownik mógł na przykład wybrać Menedżera haseł Google do utworzenia klucza dostępu. Aby uzyskać dostęp do klucza dostępu na nowym urządzeniu, musi ponownie zalogować się na konto Google i podać blokadę ekranu z poprzedniego urządzenia.

Więcej informacji znajdziesz w artykule Bezpieczeństwo kluczy dostępu w Menedżerze haseł Google.

Implementacja

Klucze dostępu są obsługiwane na urządzeniach z Androidem 9 (poziom API 28) lub nowszym. Hasła i logowanie się przez Google są obsługiwane od Androida 4.4. Aby zacząć korzystać z kluczy dostępu, wykonaj te czynności:

  1. Aby poznać podstawy implementacji kluczy dostępu, wykonaj ćwiczenie z instrukcjami dotyczące Menedżera danych logowania.
  2. Zapoznaj się z wskazówkami dotyczącymi projektowania interfejsu użytkownika kluczy dostępu. W tym dokumencie znajdziesz rekomendowane ścieżki dla Twojego przypadku użycia.
  3. Zapoznaj się z Menedżerem danych logowania, korzystając z tego przewodnika.
  4. Zaplanuj wdrożenie Menedżera danych logowania i kluczy dostępu w swojej aplikacji. Zaplanuj dodanie obsługi Digital Asset Links.

Więcej informacji o tworzeniu, rejestrowaniu i uwierzytelnianiu za pomocą kluczy dostępu znajdziesz w naszej dokumentacji dla deweloperów.

Bezpieczne resetowanie konta

Nieautoryzowany atakujący, który ma dostęp do odblokowanego urządzenia (np. gdy telefon zostanie skradziony), będzie próbował uzyskać dostęp do aplikacji zawierających poufne dane, zwłaszcza aplikacji bankowych lub aplikacji do obsługi płatności. Jeśli aplikacja korzysta z weryfikacji biometrycznej, osoba przeprowadzająca atak spróbuje zresetować konto, aby uzyskać do niego dostęp. Proces resetowania konta nie może opierać się wyłącznie na informacjach łatwo dostępnych na urządzeniu, takich jak linki do resetowania wysyłane e-mailem lub SMS-em.

Oto sprawdzone metody, które możesz zastosować w procesie resetowania aplikacji:

  • rozpoznawanie twarzy oprócz kodu OTP,
  • Pytania zabezpieczające
  • czynnik wiedzy (np. nazwisko panieńskie matki, miasto urodzenia lub ulubiona piosenka);
  • Weryfikacja za pomocą dokumentu tożsamości

SMS Retriever API

Interfejs API SMS Retriever umożliwia automatyczne weryfikowanie użytkowników aplikacji na Androida przy użyciu SMS-ów. Dzięki temu użytkownik nie będzie musiał ręcznie wpisywać kodów weryfikacyjnych. Ponadto ten interfejs API nie prosi użytkownika o dodatkowe, potencjalnie niebezpieczne uprawnienia aplikacji, takie jak RECEIVE_SMS czy READ_SMS. Nie należy jednak używać SMS-ów jako jedynej metody weryfikacji użytkownika, aby chronić urządzenie przed nieautoryzowanym dostępem lokalnym.

Jak to pomaga ograniczyć oszustwa

Niektórzy użytkownicy używają kodów SMS jako jedynego czynnika uwierzytelniania, co ułatwia oszustwa.

Interfejs API SMS Retriever umożliwia aplikacji bezpośrednie pobieranie kodu SMS bez interakcji użytkownika i może zapewniać pewien poziom ochrony przed oszustwami.

Implementacja

Implementacja interfejsu SMS Retriever API składa się z 2 części: Android i serwer.

Android: (przewodnik)

  1. Uzyskaj numer telefonu użytkownika.
  2. Uruchom klienta pobierania SMS-ów.
  3. Wyślij numer telefonu na serwer.
  4. otrzymywać wiadomości weryfikacyjne;
  5. Wyślij jednorazowe hasło na swój serwer.

Serwer: (przewodnik)

  1. Utwórz wiadomość weryfikacyjną.
  2. Wyślij wiadomość weryfikacyjną SMS-em.
  3. Po otrzymaniu hasła jednorazowego sprawdź je.

Sprawdzone metody

Gdy aplikacja jest zintegrowana, a numer telefonu użytkownika jest weryfikowany za pomocą interfejsu SMS Retriever API, próbuje ona uzyskać hasło jednorazowe. Jeśli się to uda, będzie to silny sygnał, że SMS został automatycznie odebrany na urządzeniu. Jeśli się nie powiedzie i użytkownik musi ręcznie wpisać kod OTP, może to być sygnał ostrzegawczy, że użytkownik może być ofiarą oszustwa.

SMS-y nie powinny być jedynym mechanizmem weryfikacji użytkownika, ponieważ pozostawiają pole do ataków lokalnych, np. ataku na skradzione odblokowane urządzenie lub ataku polegającego na sklonowaniu karty SIM. Zalecamy korzystanie z danych biometrycznych, gdy tylko jest to możliwe. Na urządzeniach, na których nie ma czujników biometrycznych, uwierzytelnianie użytkownika powinno opierać się na co najmniej jednym czynniku, którego nie można łatwo uzyskać z bieżącego urządzenia.

Więcej informacji

Więcej informacji o sprawdzonych metodach znajdziesz w tych artykułach: