Zum Schutz Ihres Authentifizierungssystems unter Android sollten Sie auf ein passwortbasiertes Modell verzichten. Dies gilt insbesondere für vertrauliche Konten wie die Bank- und E-Mail-Konten Ihrer Nutzer. Denken Sie daran, dass einige Apps, die Ihre Nutzer installieren, möglicherweise nicht die besten Absichten haben und versuchen, Ihre Nutzer per Phishing zu betreiben.
Gehen Sie außerdem nicht davon aus, dass nur autorisierte Nutzer das Gerät verwenden. Der Diebstahl von Smartphones ist ein häufiges Problem und Angreifer wählen entsperrte Geräte aus, um direkt von Nutzerdaten oder Finanz-Apps zu profitieren. Wir empfehlen für alle sensiblen Anwendungen ein angemessenes Zeitlimit für die Authentifizierung (15 Minuten?) mit biometrischer Überprüfung und eine zusätzliche Authentifizierung vor sensiblen Aktionen wie Geldtransfers.
Dialogfeld für biometrische Authentifizierung
Die Biometrics-Bibliothek bietet eine Reihe von Funktionen zum Anzeigen einer Aufforderung, die eine biometrische Authentifizierung wie Gesichtserkennung oder Fingerabdruckerkennung anfordert. Biometrische Aufforderungen können jedoch so konfiguriert werden, dass sie auf das LSKF zurückgreifen, wo bekannte Risiken beim Surfen auf der Schulter bestehen. Bei sensiblen Anwendungen empfehlen wir, kein biometrisches Fallback auf die PIN zu verwenden. Wenn die biometrischen Wiederholungsversuche ausgeschöpft wurden, können Nutzer warten, sich mit einem Passwort neu anmelden oder ihre Konten zurücksetzen. Zum Zurücksetzen des Kontos sollten Faktoren erforderlich sein, die auf dem Gerät nicht leicht zugänglich sind (Best Practice unten).
So trägt dies zum Schutz vor Betrug und Smartphone-Diebstahl bei
Ein besonderer Anwendungsfall, der bei der Betrugsprävention helfen kann, ist die Anforderung einer biometrischen Authentifizierung in Ihrer Anwendung vor einer Transaktion. Wenn Ihre Nutzer eine Finanztransaktion ausführen möchten, wird das Dialogfeld mit den biometrischen Daten angezeigt, um zu überprüfen, ob es sich tatsächlich um den beabsichtigten Nutzer handelt, der die Transaktion durchführt. Diese Best Practice schützt davor, dass ein Angreifer ein Gerät stiehlt, unabhängig davon, ob der Angreifer den LSKF kennt oder nicht, da er prüfen muss, ob er der Eigentümer des Geräts ist.
Für zusätzliche Sicherheitsebenen empfehlen wir App-Entwicklern, eine biometrische Authentifizierung der Klasse 3 anzufordern und CryptoObject
für Bank- und Finanztransaktionen zu verwenden.
Implementierung
- Achte darauf, die androidx.biometric-Bibliothek anzugeben.
- Fügen Sie das Dialogfeld für die biometrische Anmeldung in die Aktivität oder das Fragment ein, das die Logik enthält, die der Nutzer authentifizieren soll.
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); }); }
Best Practices
Wir empfehlen Ihnen, mit dem Codelab zu beginnen, um mehr über biometrische Verfahren zu erfahren.
Je nach Anwendungsfall können Sie den Dialog mit oder ohne explizite Nutzeraktion implementieren. Um Betrug zu vermeiden, sollten Sie das biometrische Dialogfeld mit expliziter Nutzeraktion für jede Transaktion hinzufügen. Uns ist bewusst, dass die Einbindung der Authentifizierung zu Problemen im UX-Design führen kann. Da die Informationen, die in einer Banktransaktion verarbeitet werden, und die biometrische Authentifizierung reibungsloser als andere Authentifizierungsmethoden ist, halten wir es für notwendig, diese Navigationsebene hinzuzufügen.
Weitere Informationen zur biometrischen Authentifizierung
Passkeys
Passkeys sind eine sichere und einfache Alternative zu Passwörtern. Passkeys verwenden Public-Key-Kryptografie, damit sich Ihre Nutzer über die Displaysperre ihres Geräts, z. B. per Fingerabdruck oder Gesichtserkennung, in Apps und Websites anmelden können. Dadurch müssen sich Nutzer keine Passwörter mehr merken und sie müssen sie nicht mehr verwalten. Außerdem wird die Sicherheit erheblich verbessert.
Passkeys erfüllen die Anforderungen an die Multi-Faktor-Authentifizierung in einem einzigen Schritt. Sie ersetzen sowohl ein Passwort als auch OTP-Codes, um robusten Schutz vor Phishing-Angriffen zu bieten und Nutzern die Probleme durch SMS- oder App-basierte Einmalpasswörter zu ersparen. Da Passkeys standardisiert sind, ermöglicht eine einzige Implementierung eine passwortlose Nutzung auf allen Geräten, Browsern und Betriebssystemen der Nutzer.
Auf Android-Geräten werden Passkeys über die Jetpack-Bibliothek von Credential Manager unterstützt, die die wichtigsten Authentifizierungsmethoden vereinheitlicht, darunter Passkeys, Passwörter und die föderierte Anmeldung (z. B. „Über Google anmelden“).
So trägt dies zur Eindämmung von Betrug bei
Passkeys schützen Sie vor Phishing-Angriffen, da sie nur bei Ihren registrierten Apps und Websites funktionieren.
Die Hauptkomponente eines Passkeys ist ein kryptografischer privater Schlüssel. In der Regel befindet sich dieser private Schlüssel ausschließlich auf Ihren Geräten wie Laptops oder Smartphones und wird von Anmeldedatenanbietern (auch Passwortmanagern) wie Google Passwortmanager zwischen ihnen synchronisiert. Beim Erstellen eines Passkeys wird nur der entsprechende öffentliche Schlüssel vom Onlinedienst gespeichert. Während der Anmeldung verwendet der Dienst den privaten Schlüssel, um eine Identitätsbestätigung über den öffentlichen Schlüssel zu signieren. Diese kann nur von einem Ihrer Geräte stammen. Dazu müssen Sie außerdem Ihr Gerät oder Ihren Anmeldedatenspeicher entsperren, um nicht autorisierte Anmeldungen zu verhindern (z. B. von einem gestohlenen Smartphone).
Um einen unbefugten Zugriff bei einem gestohlenen, entsperrten Gerät zu verhindern, müssen Passkeys mit einem sinnvollen Zeitlimit für die Authentifizierung gekoppelt werden. Ein Angreifer, der ein Gerät stiehlt, sollte eine Anwendung nicht verwenden können, nur weil der vorherige Nutzer angemeldet war. Stattdessen sollten die Anmeldedaten in regelmäßigen Abständen (z. B. alle 15 Minuten) ablaufen. Außerdem sollten Nutzer ihre Identität über die erneute Authentifizierung der Displaysperre bestätigen müssen.
Wenn Ihr Smartphone gestohlen wird, schützen Passkeys Sie, weil Diebe Ihre Passwörter nicht stehlen können, um sie auf anderen Geräten zu verwenden. Passkeys sind gerätespezifisch. Wenn du den Google Passwortmanager verwendest und dein Smartphone gestohlen wird, kannst du dich auf einem anderen Gerät (z. B. einem Computer) in deinem Google-Konto anmelden und dich per Fernzugriff von dem gestohlenen Smartphone abmelden. Dadurch kann der Google Passwortmanager auf dem gestohlenen Smartphone nicht mehr verwendet werden, einschließlich aller gespeicherten Passkeys.
Im schlimmsten Fall werden Passkeys von dem Anmeldedatenanbieter, der den Passkey erstellt und synchronisiert hat, wieder mit dem neuen Gerät synchronisiert, wenn das gestohlene Gerät nicht wiederhergestellt wird. Wenn der Nutzer beispielsweise den Passkey über den Google Passwortmanager erstellt hat, kann er auf einem neuen Gerät auf seinen Passkey zugreifen, indem er sich wieder in seinem Google-Konto anmeldet und die Displaysperre des vorherigen Geräts verwendet.
Weitere Informationen finden Sie im Artikel Sicherheit von Passkeys im Google Passwortmanager.
Implementierung
Passkeys werden auf Geräten mit Android 9 (API-Level 28) oder höher unterstützt. Passwörter und die Funktion „Über Google anmelden“ werden ab Android 4.4 unterstützt. So verwenden Sie Passkeys:
- Im Codelab für Anmeldedaten-Manager kannst du dich mit der Implementierung von Passkeys vertraut machen.
- Lies dir die Designrichtlinien für Passkeys durch. In diesem Dokument erfahren Sie, welche Abläufe für Ihren Anwendungsfall empfohlen werden.
- Lies dir die Informationen zum Credential Manager durch. Eine Anleitung dazu findest du in diesem Leitfaden.
- Planen Sie die Implementierung des Anmeldedaten-Managers und der Passkeys für Ihre App und fügen Sie die Unterstützung für Digital Asset Links hinzu.
Weitere Informationen zum Erstellen, Registrieren und Authentifizieren mit Passkeys finden Sie in unserer Entwicklerdokumentation.
Zurücksetzen des sicheren Kontos
Ein nicht autorisierter Angreifer, der Zugriff auf ein entsperrtes Gerät hat (z. B. wenn ein Smartphone gestohlen wurde), versucht, auf sensible Apps zuzugreifen, insbesondere auf Bank- oder Bargeld-Apps. Wenn die Anwendung die biometrische Verifizierung implementiert, versucht der Angreifer, das Konto zurückzusetzen, um wieder Zugriff zu erhalten. Es ist wichtig, dass sich das Konto nicht nur auf Informationen stützt, die auf dem Gerät leicht zugänglich sind, z. B. Links zum Zurücksetzen von OTP per E-Mail oder SMS.
Im Folgenden finden Sie gängige Best Practices, die Sie beim Zurücksetzen Ihrer App berücksichtigen können:
- Gesichtserkennung und OTP
- Sicherheitsfragen
- Wissensfaktor (z. B. Mädchenname der Mutter, Geburtsort oder Lieblingslied)
- Bestätigung per Ausweis
SMS Retriever-API
Mit der SMS Retriever API können Sie in Ihrer Android-App automatisch eine SMS-basierte Nutzerbestätigung durchführen. Auf diese Weise muss der Nutzer Bestätigungscodes nicht manuell eingeben. Außerdem fordert diese API den Nutzer nicht nach zusätzlichen, potenziell gefährlichen App-Berechtigungen wie RECEIVE_SMS
oder READ_SMS
an. SMS sollten jedoch nicht als einzige Nutzerbestätigung zum Schutz vor nicht autorisiertem lokalen Zugriff auf das Gerät verwendet werden.
So trägt dies zur Eindämmung von Betrug bei
Einige Nutzer verwenden SMS-Codes als einzigen Authentifizierungsfaktor, der einen einfachen Einstiegspunkt für Betrug bietet.
Mit der SMS Retriever API kann die App den SMS-Code direkt ohne Nutzerinteraktion abrufen und bietet einen gewissen Schutz vor Betrug.
Implementierung
Die Implementierung der SMS Retriever API besteht aus zwei Teilen: Android und Server.
Android: (Anleitung)
- Ermitteln Sie die Telefonnummer des Nutzers.
- Starten Sie den SMS-Abrufclient.
- Senden Sie die Telefonnummer an Ihren Server.
- Bestätigungs-E-Mails erhalten.
- Senden Sie das OTP an Ihren Server.
Server: (Anleitung)
- Erstellen Sie eine Bestätigungsnachricht.
- Senden Sie die Bestätigungsnachricht per SMS.
- Prüfen Sie das OTP, wenn es zurückgegeben wird.
Best Practices
Nachdem die App integriert wurde und die Telefonnummer des Nutzers mit der SMS Retriever API verifiziert wurde, wird versucht, das OTP abzurufen. Ist sie erfolgreich, ist das ein deutliches Zeichen dafür, dass die SMS automatisch auf dem Gerät empfangen wurde. Wenn das nicht funktioniert und der Nutzer das OTP manuell eingeben muss, kann dies ein Warnsignal für einen Betrugsversuch sein.
SMS sollten nicht als einziger Mechanismus zur Nutzerbestätigung verwendet werden, da sie Raum für lokale Angriffe lassen, z. B. wenn ein Angreifer ein entsperrtes Gerät ausspioniert, oder das Klonen von SIM-Karten. Es wird empfohlen, nach Möglichkeit das biometrische Verfahren zu verwenden. Bei Geräten, auf denen keine biometrischen Sensoren verfügbar sind, sollte die Nutzerauthentifizierung auf mindestens einem Faktor beruhen, der vom aktuellen Gerät nicht leicht abgerufen werden kann.
Weitere Informationen
Weitere Informationen zu den Best Practices finden Sie in den folgenden Ressourcen:
- Unsere Android-Dokumentation zur Sicherheit
- Dokumentation zur Play Integrity API
- Änderungen bei Android 15
- Best Practices der Monzo Bank zum Schutz vor Betrugsanrufen