Pour protéger votre système d'authentification sous Android, envisagez d'utiliser basé sur un mot de passe, surtout pour les comptes sensibles banque et des comptes de messagerie. N'oubliez pas que certaines applications installées par vos utilisateurs peuvent ne pas disposer et tenter d'hameçonner vos utilisateurs.
De plus, ne partez pas du principe que seuls les utilisateurs autorisés se serviront de l'appareil. Vol de téléphone est un problème courant, et les attaquants ciblent les appareils déverrouillés pour en tirer profit à partir des données utilisateur ou des applications financières. Nous suggérons à toutes les applications sensibles d'implémenter un délai d'authentification raisonnable (15 minutes ?) avec la vérification biométrique et Exiger une authentification supplémentaire avant d'effectuer des actions sensibles, comme l'argent transferts.
Boîte de dialogue d'authentification biométrique
La bibliothèque Biometrics propose un ensemble de fonctions permettant d'afficher une requête l'authentification biométrique (reconnaissance faciale ou empreinte digitale, par exemple). Cependant, les requêtes biométriques peuvent être configurées pour se rabattre sur LSKF, risques connus liés à la planche d'épaule. Pour les applications sensibles, nous vous recommandons l'absence de basculement biométrique sur le code PIN, et après avoir épuisé les tentatives les utilisateurs peuvent patienter, se reconnecter avec un mot de passe ou réinitialiser les comptes. Compte réinitialisé Nécessitent des facteurs auxquels il est difficile d'accéder sur l'appareil ci-dessous).
En quoi cela permet-il de limiter la fraude et le vol de téléphone ?
Un cas d'utilisation particulier qui peut aider à prévenir la fraude est de demander l'authentification biométrique dans votre application avant une transaction. Lorsque vos utilisateurs effectuer une transaction financière, la boîte de dialogue biométrique s'affiche vérifier que c'est bien l'utilisateur destiné à effectuer la transaction. Ce la meilleure pratique consisterait à protéger contre un attaquant qui vole un appareil, quel que soit si l’attaquant connaît ou non le LSKF, car il devra vérifier qu’il le propriétaire de l'appareil.
Pour renforcer la sécurité, nous recommandons aux développeurs d'applications de demander la classe 3.
l'authentification biométrique, et d'utiliser CryptoObject pour les opérations bancaires et
les transactions financières.
Implémentation
- Veillez à inclure la bibliothèque androidx.biometric.
- Inclure la boîte de dialogue de connexion biométrique dans l'activité ou le fragment contenant la logique avec laquelle vous souhaitez authentifier l'utilisateur.
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 une action explicite de l'utilisateur. Pour éviter toute fraude, nous vous conseillons d'ajouter boîte de dialogue avec une action explicite de l'utilisateur pour chaque transaction. Nous savons que l'ajout d'une authentification peut créer des frictions dans l'UX, mais en raison de la nature de les informations traitées lors d'une transaction bancaire et que l'authentification biométrique est plus fluide que les autres méthodes d'authentification, pour 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. Utilisation des clés d'accès la cryptographie à clé publique pour permettre à vos utilisateurs de se connecter à des applications et à des sites Web En utilisant le mécanisme de verrouillage de l'écran de son appareil (empreinte digitale ou visage, par exemple) de la reconnaissance vocale. Cela évite à l'utilisateur d'avoir à mémoriser et à gérer des mots de passe, et améliore considérablement la sécurité.
Les clés d'accès peuvent répondre aux exigences d'authentification multifacteur en une seule étape, en remplaçant à la fois un mot de passe et des codes OTP pour offrir une protection efficace contre les attaques par hameçonnage et évitent l'expérience utilisateur fastidieuse liée aux SMS ou aux applications mots de passe. Les clés d'accès étant standardisées, une seule implémentation permet sans mot de passe pour tous les utilisateurs appareils, navigateurs et systèmes d'exploitation.
Sur Android, les clés d'accès sont compatibles avec le Jetpack Gestionnaire d'identifiants. qui unifie les principales méthodes d'authentification, y compris les clés d'accès, mots de passe et connexion fédérée (par exemple, Se connecter avec Google).
En quoi cela permet-il de limiter la fraude ?
Les clés d'accès vous protègent des attaques d'hameçonnage, car elles ne fonctionnent applications et sites Web enregistrés.
Le composant principal d'une clé d'accès est une clé privée cryptographique. En général, cela la clé privée réside uniquement sur vos appareils, tels que les ordinateurs portables ou les téléphones mobiles, et sont synchronisées entre eux par les fournisseurs d'identifiants gestionnaires de mots de passe), tels que le Gestionnaire de mots de passe de Google. Seule la clé publique correspondante est enregistrées 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. Cela ne peut proviennent de l'un de vos appareils. De plus, pour que cela se produise, vous devez déverrouiller votre appareil ou le 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 et de déverrouillage d'appareil, Les clés d'accès doivent être associées à un délai d'expiration d'authentification raisonnable. Une un attaquant qui vole un appareil ne devrait pas pouvoir utiliser une application juste car l'utilisateur précédent était connecté. Les identifiants doivent plutôt expirent à intervalles réguliers (par exemple, toutes les 15 minutes) et les utilisateurs qu'il doit valider son identité en réauthentifiant le verrouillage de l'écran.
Si on vous vole votre téléphone, les clés d'accès vous protègent, car les voleurs ne peuvent pas voler votre mots de passe à utiliser sur d'autres appareils : les clés d'accès sont spécifiques à chaque appareil. Si vous utilisez le Gestionnaire de mots de passe de Google et votre téléphone sont volés, connectez-vous à votre compte à partir d'un autre appareil (un ordinateur, par exemple) et déconnectez-vous à distance du téléphone volé. Cela rend le Gestionnaire de mots de passe de Google sur le téléphone volé inutilisable, 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 synchronisé avec le nouvel appareil par le fournisseur d'identifiants qui a créé et synchronisé la clé d'accès. Par exemple, l'utilisateur peut avoir choisi le Gestionnaire de mots de passe de Google pour créer la clé d'accès. Ils pourront alors y accéder sur un nouvel appareil à son compte Google et de fournir le verrouillage de l'écran appareil.
Pour en savoir plus, consultez le 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. À commencer à utiliser des clés d'accès, procédez comme suit:
- Suivez l'atelier de programmation sur le Gestionnaire d'identifiants pour découvrir comment implémenter des clés d'accès.
- Consultez les consignes de conception de l'expérience utilisateur pour les clés d'accès. Ce document présente les flux recommandés pour votre cas d'utilisation.
- Étudiez le Gestionnaire d'identifiants en suivant ce guide.
- Planifiez l'implémentation du Gestionnaire d'identifiants et des clés d'accès pour votre application. Prévoyez d'ajouter la prise en charge des liens vers des ressources numériques.
Consultez notre documentation destinée aux développeurs pour savoir comment créer, enregistrer et s'authentifier à l'aide de clés d'accès.
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 dérobé) essaient d'accéder à des applications sensibles, en particulier des applications bancaires ou de trésorerie. Si l'application met en œuvre la vérification biométrique, le pirate informatique tenterait de réinitialiser le compte à accéder. Il est essentiel que le processus de réinitialisation du compte ne se base pas uniquement à partir d'informations facilement accessibles sur l'appareil, telles qu'un mot de passe à usage unique envoyé par e-mail ou par SMS les liens de réinitialisation.
Voici quelques bonnes pratiques courantes que vous pouvez intégrer lors de la réinitialisation de votre application flux:
- Reconnaissance faciale, en plus de l'OTP
- Questions secrètes
- Facteur de connaissance (nom de jeune fille de la mère, ville de naissance ou favori, par exemple) chanson)
- Validation de l'identité
API SMS Retriever
L'API SMS Retriever vous permet d'effectuer une vérification des utilisateurs par SMS dans votre
l'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
pour obtenir des autorisations d'applications supplémentaires potentiellement dangereuses, comme RECEIVE_SMS ou
READ_SMS Cependant, les SMS ne doivent pas être utilisés comme seule vérification d'utilisateur pour
à protéger contre tout accès local
non autorisé à l’appareil.
En quoi cela permet-il de limiter la fraude ?
Certains utilisateurs utilisent les codes reçus par SMS comme seul facteur d'authentification, ce qui leur permet un point d'entrée facile pour les fraudes.
L'API SMS Retriever permet à l'application de récupérer directement le code SMS sans les interactions avec les utilisateurs et peuvent offrir un niveau de protection contre la fraude.
Implémentation
L'implémentation de l'API SMS Retriever s'effectue en deux parties: Android et Server.
Android: (guide)
- Obtenez le numéro de téléphone de l'utilisateur.
- Démarrez le client SMS Retriever.
- Envoyez le numéro de téléphone à votre serveur.
- Recevoir des messages de validation.
- Envoyez l'OTP à votre serveur.
Server (Serveur) : (guide)
- Rédigez un message de validation.
- Envoyez le message de vérification par SMS.
- Vérifiez l'OTP lorsqu'il vous est renvoyé.
Bonnes pratiques
Une fois l'intégration de l'application effectuée et la validation du numéro de téléphone de l'utilisateur auprès de l'API SMS Retriever, elle essaie d'obtenir l'OTP. Si l'opération réussit, signale que le SMS a été reçu automatiquement sur l'appareil. Si ce n'est pas le cas si l'opération réussit et que l'utilisateur doit saisir manuellement le mot de passe à usage unique, il peut s'agir d'un signe d'avertissement que l'utilisateur est peut-être victime de fraude.
Le SMS ne doit pas être utilisé comme seul mécanisme de validation de l'utilisateur s'il laisse de la place à des attaques locales, comme un attaquant qui vole un appareil déverrouillé ; ou SIM les attaques par clonage. Il est recommandé d'utiliser la biométrie autant que possible. Activé appareils où les capteurs biométriques ne sont pas disponibles, l'authentification de l'utilisateur s'appuient sur au moins un facteur difficile à obtenir avec l'appareil actuel.
En savoir plus
Pour en savoir plus sur les bonnes pratiques, consultez les ressources suivantes:
- Notre documentation Android sur la sécurité
- Documentation sur l'API Play Integrity
- Modifications apportées à Android 15
- Bonnes pratiques de Monzo Bank concernant la prévention des appels téléphoniques