Bonnes pratiques de nouvelle tentative A2F par SMS

July 27, 2021
Rédigé par
Révisé par

Bonnes pratiques de nouvelle tentative A2F par SMS

Les êtres humains sont des créatures impatientes. Ainsi, bien que les codes de vérification SMS ou d'authentification à double facteur (A2F ou 2FA) puissent être rapidement générés dans la plupart des régions du monde, nous recommandons toujours de créer des tampons de nouvelles tentatives dans les workflows de vérification. Cela permet d'éviter :

  • Le spamming accidentel d'un utilisateur avec des messages texte répétés
  • L'atteinte des limites de taux d'API
  • La fraude à la tarification ou les dépenses inutiles

Les bonnes pratiques de ce post sont rédigées pour l'API Twilio Verify, mais beaucoup d'entre elles s'appliquent indépendamment de votre fournisseur d'A2F. Associées à d'autres bonnes pratiques, comme la création d'une liste d'autorisation des codes de pays à vérifier, ces étapes peuvent vous aider à garantir que votre workflow de vérification utilisateur est aussi fluide que possible.

Lancer une application de démonstration avec les bonnes pratiques de nouvelle tentative par SMS

Ce projet est également disponible pour Quick Deploy sur Twilio Code Exchange, et aucun code n'est requis !

J'ai construit une application qui montre les bonnes pratiques décrites dans ce post. L'application est rapide à lancer puisqu'elle est construite avec Twilio Functions, l'environnement sans serveur de Twilio. Vous pouvez lancer la vôtre en suivant ces instructions.

Les prérequis sont les suivants :

  • Node.js
  • Un compte Twilio gratuit (inscrivez-vous gratuitement avec ce lien et bénéficiez d'un crédit de 10 $ lorsque vous mettez à niveau votre compte)
  • Un service Verify Créez-en un dans la console Twilio.

Clonez ou téléchargez l'exemple de projet sur mon GitHub :

git clone https://github.com/robinske/verify-retry.git && cd verify-retry

Installez les dépendances avec npm install. Renommez ensuite le fichier .env.example en .env(pour des raisons de sécurité, le fichier .env fait partie du fichier .gitignore et ne sera pas validé à la source), puis renseignez les variables avec votre Account SID et votre Auth Token, qui se trouvent dans laconsole Twilio. Renseignez le SID du service Verify que vous avez créé précédemment :

# à trouver dans la console Twilio: https://twilio.com/console
ACCOUNT_SID=
AUTH_TOKEN= 
# à créer dans la console Twilio: https://twilio.com/console/verify/services
VERIFY_SERVICE_SID=

Lancez le projet avec npm start et accédez à http://localhost:3000/index.html pour le tester.

Bonnes pratiques pour les nouvelles tentatives de codes A2F par SMS

Implémenter des délais d'expiration sur le bouton Renvoyer.

Ajoutez un tampon entre les nouvelles tentatives pour éviter de mauvais comportements ou l'envoi accidentel de plusieurs codes. Nous vous recommandons de commencer par 30 secondes.

option de code de renvoi grisée indiquant « Renvoyer le code dans 22 secondes »

Dans la démonstration, le décompte s'effectue à partir du délai maximum et le bouton reste désactivé jusqu'à l'expiration du délai. Pour une alternative moins animée, vous pouvez :

  • afficher le décompte avec 5 secondes restantes
  • griser le bouton Renvoyer jusqu'à l'expiration du délai avec une copie indiquant le tampon total (sans décompte)
  • afficher uniquement le lien de nouvelle tentative une fois le délai expiré

Effectuer le suivi des nouvelles tentatives

L'API Verify inclut une liste de tentatives de vérification dans la réponse, que vous pouvez utiliser pour augmenter le tampon de nouvelles tentatives à chaque tentative supplémentaire. Vous pouvez également utiliser le nombre de tentatives pour appliquer vos propres limites de taux en plus des limites de taux d'API Verify (les 5 vérifications sont lancées sur une durée de 10 minutes).

Cette fonction présente un exemple d'augmentation du délai d'expiration avec davantage de tentatives. Le délai d'expiration est défini par défaut sur le délai maximum (10 minutes), ce qui peut empêcher votre application d'atteindre les limites de taux de l'API.

function getRetryTimeout(attemptNumber) {
 const retryTimeouts = {
   1: 30,
   2: 40,
   3: 60,
   4: 90,
   5: 120,
 };

 return retryTimeouts[attemptNumber] || 600;
}

Bonnes pratiques pour les canaux de secours

Proposer d'autres canaux comme la voix lors de la troisième tentative de vérification

Les appels vocaux sont prioritaires dans les réseaux téléphoniques et peuvent aider vos clients à obtenir un code de vérification. Toutefois, le canal vocal peut être utilisé à des fins de fraude à la tarification. Par conséquent, à moins de détecter une ligne fixe ou de disposer d'un scénario professionnel pour les appels, nous vous recommandons de ne pas exposer ce canal avant la troisième ou quatrième tentative d'envoi de SMS ou de le désactiver complètement.

Affichez une option « Appelez-moi à la place » dans votre expérience utilisateur dès que plusieurs tentatives d'envoi de SMS ont été effectuées :

champ de saisie d'un code d'accès à usage unique avec message de renvoi de code grisé et lien cliquable indiquant « Problème de réception de SMS, appelez-moi à la place »

Détecter les lignes fixes

En plus d'utiliser l'API Lookup de Twilio pour détecter les numéros de téléphone non valides, vous pouvez utiliser l'API pour détecter les numéros de téléphone fixes et utiliser le canal call pour ces numéros au lieu de l'envoi de SMS par défaut.

Si vous saisissez une ligne fixe dans l'exemple de projet, il appellera automatiquement au lieu d'envoyer le code de vérification par SMS.

champ de saisie d'un code d'accès à usage unique avec message indiquant « ligne fixe détectée. vérification d'appel envoyée »

Désactiver les canaux inutilisés dans la console Twilio

Si vous souhaitez désactiver certains canaux, vous pouvez le faire dans la section Verify de la console Twilio.

console Twilio Verify affichant les boutons désactivés des canaux appel et e-mail

Implémenter reCAPTCHA pour les appels vocaux

Implémentez reCAPTCHA pour vous aider à détecter et à éviter les bots dans votre flux de vérification. Pour en savoir plus sur l'implémentation de cette fonctionnalité, consultez la documentation pour développeurs de Google.

Ajout de limites de taux supplémentaires

L'API Twilio Verify prend en charge des limites de taux programmables que vous pouvez appliquer à des segments particuliers en fonction de la demande, comme une adresse IP, une géolocalisation ou un code pays.

Bonnes pratiques générales de vérification utilisateur

La logique de nouvelle tentative est l'un des composants de la création d'un workflow de vérification utilisateur fluide. Voici quelques autres bonnes pratiques :

1. Utilisez l'API Lookup de Twilio pour détecter les numéros et le type de ligne non valides avant d'envoyer une vérification

Outre l'utilisation de l'API Carrier Lookup qui permet d'identifier les lignes fixes, l'API Lookup peut être utilisée pour identifier les numéros non valides avant une tentative d'envoi d'un code de vérification.

2. Créez une liste d'autorisation ou de blocage des pays

L'utilisation d'une liste d'autorisation des pays lors de l'inscription est un excellent moyen de vous assurer que vous respectez les exigences en matière de conformité, réduisez la fraude et contrôlez votre pipeline d'intégration.

3. Affichez les numéros de téléphone complets pour la vérification utilisateur initiale

Pour les cas d'usage de vérification téléphonique (par opposition à la connexion continue ou à l'authentification à double facteur), affichez le numéro de téléphone complet dans l'interface pour que l'utilisateur puisse détecter toute erreur.

champ de saisie de code d'accès à usage unique avec message indiquant le numéro de téléphone complet et une option pour le modifier.

4. Masquez les numéros de téléphone pour la connexion continue ou l'authentification à double facteur

Une fois le numéro de téléphone vérifié pour la première fois, les utilisations suivantes doivent masquer le numéro de téléphone afin d'éviter toute fuite de PII (Personally Identifiable Information). Contrairement à ce qui précède, il n'existe aucune option permettant de modifier un numéro de téléphone pour l'authentification continue. Nous recommandons d'afficher 3 ou 4 chiffres et de masquer le reste, par exemple : +1 (5**) ***-**67 ou ********567.

champ de saisie de code d'accès à usage unique avec message indiquant un numéro de téléphone masqué et aucune option pour le modifier.

Facultatif : déployer le projet avec Twilio Functions

Pour déployer ce projet avec Twilio Functions, vous aurez besoin des éléments suivants :

Une fois ces dépendances installées, vous pouvez déployer ce projet en exécutant la commande suivante à partir du dossier verify-retry :

twilo serverless:deploy

Étapes suivantes avec la vérification utilisateur

Comme l'a déclaré Miranda Wei, chercheuse en matière de confidentialité utilisable, nous devrions réfléchir à créer une sécurité utilisable sous la forme d'un « service client, dans lequel les utilisateurs tentent de garantir leur sécurité et qui change constamment. Ce n'est pas un système que l'on peut définir une seule fois puis négliger ». Ces bonnes pratiques sont un bon début, mais nous vous recommandons de surveiller vos coûts de support et la satisfaction de vos utilisateurs, pour vous assurer de fournir la meilleure solution, à mesure que votre produit et votre technologie d'authentification évoluent.

Pour des ressources supplémentaires, consultez la documentation suivante :

J'ai hâte de voir ce que vous allez construire et sécuriser !