Authentification sécurisée des utilisateurs

Pour protéger votre système d'authentification sur Android, envisagez d'abandonner un modèle basé sur les mots de passe, en particulier pour les comptes sensibles tels que les comptes bancaires et de messagerie de vos utilisateurs. N'oubliez pas que certaines applications installées par vos utilisateurs peuvent avoir de mauvaises intentions et tenter de les hameçonner.

Ne partez pas non plus du principe que seuls les utilisateurs autorisés utiliseront l'appareil. Le vol de téléphones est un problème courant. Les pirates informatiques ciblent les appareils déverrouillés pour tirer directement profit des données utilisateur ou des applications financières. Nous suggérons que toutes les applications sensibles implémentent un délai d'authentification raisonnable (15 minutes ?) avec vérification biométrique et exigent une authentification supplémentaire avant les actions sensibles telles que les transferts d'argent.

Boîte de dialogue d'authentification biométrique

La bibliothèque Biometrics propose un ensemble de fonctions permettant d'afficher une invite demandant une authentification biométrique, telle que la reconnaissance faciale ou par empreinte digitale. Toutefois, les invites biométriques peuvent être configurées pour revenir à LSKF, qui présente des risques connus de shoulder surfing. Pour les applications sensibles, nous vous recommandons de ne pas utiliser de code comme solution de secours biométrique. Après avoir épuisé les tentatives biométriques, les utilisateurs peuvent attendre, se reconnecter avec un mot de passe ou réinitialiser leurs comptes. La réinitialisation du compte doit nécessiter des facteurs qui ne sont pas facilement accessibles sur l'appareil (bonnes pratiques ci-dessous).

Comment cela permet-il de réduire la fraude et le vol de téléphones ?

Un cas d'utilisation particulier qui peut être utile pour prévenir la fraude consiste à demander une authentification biométrique dans votre application avant une transaction. Lorsque vos utilisateurs souhaitent effectuer une transaction financière, la boîte de dialogue biométrique s'affiche pour vérifier qu'il s'agit bien de l'utilisateur prévu qui effectue la transaction. Cette bonne pratique permet de se protéger contre le vol d'un appareil par un pirate informatique, qu'il connaisse ou non le LSKF, car il devra prouver qu'il est le propriétaire de l'appareil.

Pour renforcer la sécurité, nous recommandons aux développeurs d'applications de demander l'authentification biométrique de classe 3 et d'utiliser CryptoObject pour les transactions bancaires et financières.

Implémentation

  1. Assurez-vous d'inclure la bibliothèque androidx.biometric.
  2. Incluez la boîte de dialogue de connexion biométrique dans l'activité ou le fragment qui contient la logique pour laquelle vous souhaitez que l'utilisateur soit authentifié.

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);
    });
}

Bonnes pratiques

Nous vous recommandons de commencer par l'atelier de programmation pour en savoir plus sur la biométrie.

Selon vos cas d'utilisation, vous pouvez implémenter la boîte de dialogue avec ou sans action explicite de l'utilisateur. Pour éviter toute fraude, nous vous recommandons d'ajouter la boîte de dialogue biométrique avec une action explicite de l'utilisateur pour chaque transaction. Nous comprenons que l'ajout d'une authentification peut entraîner des frictions dans l'expérience utilisateur. Toutefois, en raison de la nature des informations traitées lors d'une transaction bancaire et du fait que l'authentification biométrique est plus fluide que les autres méthodes d'authentification, nous pensons qu'il est nécessaire d'ajouter ce niveau de navigation.

En savoir plus sur l'authentification biométrique

Clés d'accès

Les clés d'accès offrent une alternative aux mots de passe, à la fois plus sécurisée et plus simple. Les clés d'accès utilisent la cryptographie à clé publique pour permettre à vos utilisateurs de se connecter à des applications et des sites Web à l'aide du mécanisme de verrouillage de l'écran de leur appareil, tel que la reconnaissance d'empreinte digitale ou faciale. L'utilisateur n'a plus besoin de mémoriser ni de gérer des mots de passe, et la sécurité est considérablement renforcée.

Les clés d'accès peuvent répondre aux exigences de l'authentification multifacteur en une seule étape. Elles remplacent à la fois un mot de passe et des mots de passe à usage unique pour offrir une protection robuste contre les attaques par hameçonnage et éviter les problèmes d'expérience utilisateur liés aux mots de passe à usage unique par SMS ou par application. Comme les clés d'accès sont standardisées, une seule implémentation permet une expérience sans mot de passe sur tous les appareils, navigateurs et systèmes d'exploitation des utilisateurs.

Sur Android, les clés d'accès sont compatibles avec la bibliothèque Jetpack Credential Manager, qui unifie les principales méthodes d'authentification, y compris les clés d'accès, les mots de passe et la connexion fédérée (comme Se connecter avec Google).

Comment cela permet d'atténuer la fraude

Les clés d'accès vous protègent contre les attaques par hameçonnage, car elles ne fonctionnent que sur les applications et les sites Web enregistrés.

Le composant principal d'une clé d'accès est une clé privée cryptographique. En règle générale, cette clé privée réside uniquement sur vos appareils, tels que les ordinateurs portables ou les téléphones mobiles, et est synchronisée sur ceux-ci par les fournisseurs d'identifiants (également appelés gestionnaires de mots de passe), tels que le Gestionnaire de mots de passe de Google. Seule la clé publique correspondante est enregistrée par le service en ligne lorsqu'une clé d'accès est créée. Lors de la connexion, le service utilise la clé privée pour signer un défi à partir de la clé publique. Cette demande ne peut provenir que de l'un de vos appareils. De plus, pour que cela se produise, vous devez déverrouiller votre appareil ou votre magasin d'identifiants, ce qui empêche les connexions non autorisées (par exemple, à partir d'un téléphone volé).

Pour empêcher tout accès non autorisé en cas de vol d'un appareil déverrouillé, les clés d'accès doivent être associées à un délai d'authentification raisonnable. Un pirate informatique qui vole un appareil ne doit pas pouvoir utiliser une application simplement parce que l'utilisateur précédent était connecté. Au lieu de cela, les identifiants doivent expirer à intervalles réguliers (par exemple, toutes les 15 minutes), et les utilisateurs doivent être tenus de valider leur identité en se réauthentifiant sur l'écran de verrouillage.

Si votre téléphone est volé, les clés d'accès vous protègent, car les voleurs ne peuvent pas dérober vos mots de passe pour les utiliser sur d'autres appareils. En effet, les clés d'accès sont spécifiques à un appareil. Si vous utilisez le Gestionnaire de mots de passe de Google et que votre téléphone est volé, vous pouvez vous connecter à votre compte Google depuis un autre appareil (comme un ordinateur) et vous déconnecter à distance du téléphone volé. Le Gestionnaire de mots de passe de Google devient inutilisable sur le téléphone volé, y compris les clés d'accès enregistrées.

Dans le pire des cas, si l'appareil volé n'est pas récupéré, les clés d'accès sont resynchronisées sur le nouvel appareil par le fournisseur d'identifiants qui les a créées et synchronisées. Par exemple, l'utilisateur peut avoir choisi le Gestionnaire de mots de passe de Google pour créer la clé d'accès. Il peut accéder à sa clé d'accès sur un nouvel appareil en se reconnectant à son compte Google et en fournissant le code de déverrouillage de l'écran de l'appareil précédent.

Pour en savoir plus, consultez l'article Sécurité des clés d'accès dans le Gestionnaire de mots de passe de Google.

Implémentation

Les clés d'accès sont compatibles avec les appareils équipés d'Android 9 (niveau d'API 28) ou version ultérieure. Les mots de passe et la fonctionnalité Se connecter avec Google sont compatibles à partir d'Android 4.4. Pour commencer à utiliser les clés d'accès, procédez comme suit :

  1. Suivez l'atelier de programmation Credential Manager pour comprendre comment implémenter des clés d'accès.
  2. Consultez les consignes de conception de l'expérience utilisateur avec les clés d'accès. Ce document vous indique les flux recommandés pour votre cas d'utilisation.
  3. Étudiez le Gestionnaire d'identifiants en suivant le guide.
  4. Planifiez l'implémentation du Gestionnaire d'identifiants et des clés d'accès pour votre application. Planifiez l'ajout de la prise en charge de Digital Asset Links.

Pour en savoir plus sur la création, l'enregistrement et l'authentification avec des clés d'accès, consultez notre documentation pour les développeurs.

Réinitialisation sécurisée du compte

Un pirate informatique non autorisé ayant accès à un appareil déverrouillé (par exemple, lorsqu'un téléphone est volé) tentera d'accéder à des applications sensibles, en particulier les applications bancaires ou de paiement. Si l'application implémente la vérification biométrique, l'attaquant tentera de réinitialiser le compte pour y accéder. Il est essentiel que le processus de réinitialisation du compte ne repose pas uniquement sur des informations facilement accessibles sur l'appareil, telles que les liens de réinitialisation par e-mail ou par code secret à usage unique par SMS.

Voici quelques bonnes pratiques courantes que vous pouvez intégrer au flux de réinitialisation de votre application :

  • Reconnaissance faciale, en plus du code secret à usage unique
  • Questions secrètes
  • Un facteur de connaissance (comme le nom de jeune fille de votre mère, votre ville de naissance ou votre chanson préférée)
  • Pièce d'identité

API SMS Retriever

L'API SMS Retriever vous permet de valider automatiquement les utilisateurs par SMS dans votre application Android. Ainsi, l'utilisateur n'aura pas besoin de saisir manuellement les codes de validation. De plus, cette API ne demande pas à l'utilisateur des autorisations d'application supplémentaires potentiellement dangereuses, comme RECEIVE_SMS ou READ_SMS. Toutefois, les SMS ne doivent pas être utilisés comme seule méthode de validation de l'utilisateur pour protéger l'accès local non autorisé à l'appareil.

Comment cela permet d'atténuer la fraude

Certains utilisateurs n'utilisent que des codes SMS comme facteur d'authentification, ce qui constitue un point d'entrée facile pour la fraude.

L'API SMS Retriever permet à l'application de récupérer directement le code SMS sans interaction de l'utilisateur et peut offrir un certain niveau de protection contre la fraude.

Implémentation

L'implémentation de l'API SMS Retriever se fait en deux parties : Android et serveur.

Android : (guide)

  1. Obtenez le numéro de téléphone de l'utilisateur.
  2. Démarrez le client SMS Retriever.
  3. Envoyez le numéro de téléphone à votre serveur.
  4. recevoir des messages de validation ;
  5. Envoyez le code OTP à votre serveur.

Serveur : (guide)

  1. Rédigez un message de validation.
  2. Envoyez le message de validation par SMS.
  3. Validez le code OTP lorsqu'il est renvoyé.

Bonnes pratiques

Une fois l'application intégrée et le numéro de téléphone de l'utilisateur validé avec l'API SMS Retriever, elle tente d'obtenir le code OTP. Si l'opération réussit, cela indique que le SMS a été reçu automatiquement sur l'appareil. Si l'opération échoue et que l'utilisateur doit saisir manuellement le code secret à usage unique, cela peut être un signe d'une éventuelle fraude.

Les SMS ne doivent pas être utilisés comme seul mécanisme de validation de l'utilisateur, car ils laissent la porte ouverte aux attaques locales, comme un attaquant qui vole un appareil déverrouillé ou des attaques de clonage de carte SIM. Nous vous recommandons d'utiliser l'authentification biométrique dans la mesure du possible. Sur les appareils où les capteurs biométriques ne sont pas disponibles, l'authentification de l'utilisateur doit reposer sur au moins un facteur qui n'est pas facilement obtenu à partir de l'appareil actuel.

En savoir plus

Pour en savoir plus sur les bonnes pratiques, consultez les ressources suivantes :