Limites de l’authentification par mot de passe

Selon l'enquête 2023 Password Decisions Survey menée par Bitwarden, les mécanismes d'authentification traditionnels par email/mot de passe ne sont plus suffisants pour assurer la sécurité des applications mobiles. Voici quelques résultats clés de l'enquête qui mettent en évidence les limites et les risques associés à l'authentification basée sur les mots de passe :

1. Habitudes de mots de passe au travail : 84% des répondants utilisent un logiciel de gestion de mots de passe, mais des pratiques risquées comme la sauvegarde de mots de passe sur des documents sur leur ordinateur (54%) ou la dépendance à la mémoire (45%).
2. Méthodes de partage de mots de passe : Bien que 66% des décideurs en informatique partagent des mots de passe via un gestionnaire de mots de passe, un nombre important partage également via des e-mails et des documents en ligne.
3. Réutilisation de mots de passe : Il est important de souligner que presque tous les répondants (90%) réutilisent des mots de passe sur plusieurs sites, ce qui augmente le risque si un des sites est compromis.
4. Authentification à deux facteurs (2FA) : Bien que 92% des répondants utilisent 2FA sur le lieu de travail, 48% estiment que les personnes qui sont réticentes à utiliser 2FA ne sont pas conscientes de ses avantages.
5. Cyberattaques : Le pourcentage de répondants signalant des cyberattaques est passé à 60% cette année, contre 54% l'année dernière.

Les applications mobiles continuent de traiter des données plus sensibles, il est donc crucial de prendre des mesures pour améliorer la sécurité. On vous présente dans la suite de cette newsletter, quelques solutions possibles avec leurs avantages et leurs inconvénients !

‍

One Time Passcode (OTP)

Un One-Time Passcode, ou code de passe à usage unique en français, est un code de sécurité qui est valable pour une seule session ou une seule transaction. Ce code est souvent utilisé dans les systèmes d'authentification 2FA ou MFA pour ajouter une couche supplémentaire de sécurité en combinant quelque chose que vous savez (un mot de passe) et quelque chose que vous avez (un téléphone). Si le mot de passe est compromis, la réception d'un mot de passe à usage unique par SMS peut protéger le compte.

‍

‍

Voici son fonctionnement générale:

• Demande de code OTP : L'utilisateur tente de se connecter à un compte ou de réaliser une transaction nécessitant une authentification supplémentaire. Après avoir saisi ses identifiants de base (comme un nom d'utilisateur et un mot de passe), il demande un code OTP.
• Génération du code OTP : Le serveur génère un code OTP unique. La génération de ce code est souvent basée sur un algorithme qui peut prendre en compte l'heure actuelle, la date, ou d'autres informations uniques à la transaction ou à la session.
• Envoi du code OTP : Le code OTP est ensuite envoyé à l'utilisateur via un canal de communication séparé, généralement un message SMS sur le téléphone mobile de l'utilisateur, un email, ou via une application d'authentification.
• Saisie du code OTP : L'utilisateur reçoit le code OTP et l'entre dans l'interface qui le demande.
• Vérification du code OTP : Le serveur vérifie que le code OTP entré par l'utilisateur correspond au code OTP qu'il a généré. Si c'est le cas, l'utilisateur est authentifié et la transaction ou la session peut continuer.

Avantages

1. Sécurité améliorée : Les OTP fournissent une couche supplémentaire de sécurité par rapport à un simple mot de passe. Même si un attaquant obtient votre mot de passe, il lui faudrait également accéder à votre OTP pour se connecter à votre compte.
2. Usage unique : Comme leur nom l'indique, les OTP sont conçus pour être utilisés une seule fois. Cela signifie qu'un OTP volé ou intercepté devient inutile une fois qu'il a été utilisé.
3. Validité limitée dans le temps : Les OTP ont généralement une durée de validité limitée, ce qui signifie qu'un OTP non utilisé expirera après un certain temps. Cela réduit encore le risque qu'un OTP volé ou intercepté puisse être utilisé de manière abusive.

Inconvénients

• La vérification par OTP ne propose pas une UX optimale. En effet, l'utilisateur doit taper son numéro de téléphone, attendre que le SMS arrive, retaper le code, et ce n'est qu'ensuite qu'il peut continuer à utiliser l'application. Cela peut être facilité avec la fonctionnalité de remplissage automatique disponible depuis iOS 12 et Android 8.
• Les vulnérabilités dans les réseaux mobiles, comme les failles du réseau SS7, peuvent permettre à des attaquants d'intercepter les SMS contenant des OTP.
• Attaques de phishing : Bien que les OTP puissent aider à protéger contre de nombreuses formes d'attaques, ils ne sont pas efficaces contre les attaques de phishing. Si un utilisateur est trompé pour entrer son OTP sur un site de phishing, l'attaquant peut alors utiliser l'OTP pour accéder au compte de l'utilisateur.
• SMS Pumping Attacks : Une forme d'attaque où les pirates exploitent les systèmes SMS connectés à des formulaires en ligne ou à des applications web. Ils utilisent des bots pour entrer automatiquement des numéros de téléphone à tarif premium, ce qui peut coûter cher aux entreprises qui envoient les OTP. Twitter a supprimé leur 2FA à cause d'une facture annuelle de 60 millions.

Le NIST (National Institute of Standards and Technology) a d’ailleurs proposé de déprécier l'utilisation des SMS comme facteur d'authentification

Questions…and buzz surrounding draft NIST Special Publication 800-63-3

Time based One Time Password (TOTP)

L’inconvénient majeur de l’OTP est la nécessité d’envoyer le code à usage unique via un SMS qui est un vecteur d’attaque important. Avec le TOTP, nous pouvons utiliser une application d’authentification (comme Google Authenticator ou Duo Mobile) pour générer un OTP directement depuis notre téléphone avec une durée de vie très limité qui change après un certain délai (généralement toutes les 30 secondes ou 1 minute).

Voici son fonctionnement général :

• Initialisation : Lors de la mise en place de TOPT, un secret partagé est généré. Ce secret est alors stocké à la fois par le service qui requiert l'authentification (par exemple, le serveur de votre application) et par le téléphone de l'utilisateur via une application d’authentification. Ce secret partagé peut être transféré via un QR code que l'utilisateur scanne avec son appareil.
• Génération du TOPT : À chaque fois qu'un TOPT est requis, l'application d’authentification utilise le secret partagé et le temps actuel pour générer un OTP.
• Vérification du TOPT : L'utilisateur entre le TOPT dans le service qui requiert l'authentification. Ce service génère également un TOPT à partir du secret partagé et du temps actuel, puis compare ce TOPT généré avec celui entré par l'utilisateur. Si les deux correspondent, l'authentification est réussie.
• Expiration du TOPT : Le TOPT change à chaque nouveau pas de temps. Cela signifie qu'un TOPT donné n'est valide que pendant une courte période de temps. Si un TOPT est intercepté par un attaquant, il sera inutile une fois le temps écoulé.

Avantages

• Sécurité renforcée : Les TOTP sont générés en utilisant un secret partagé et le temps actuel, ce qui rend difficile pour un attaquant de prédire le prochain mot de passe. De plus, contrairement aux OTP basés sur les SMS, les TOTP ne dépendent pas du réseau de téléphonie mobile, ce qui élimine les risques liés à l'interception des SMS.
• Hors ligne : Les TOTP peuvent être générés même lorsque l'appareil n'est pas connecté à Internet.
• Pricing : Comme on ne dépend pas d’un opérateur mobile, les coûts sont plus faibles.

Inconvénients

• Dépendance à une application tierce : Cela peut ajouter une couche supplémentaire de complexité et être perçu comme un obstacle, surtout pour les utilisateurs moins technophiles. De plus, le fait de devoir basculer entre l'application d'authentification et l'application ou le service pour lequel l'authentification est nécessaire peut entraîner une expérience utilisateur moins fluide.
• Synchronisation du temps : Les TOTP dépendent de la synchronisation du temps entre le serveur et l'appareil client. Si les horloges ne sont pas correctement synchronisées, l'OTP généré peut ne pas être valide.
• Perte de l'appareil : Si l'utilisateur perd l'appareil sur lequel sont générés les TOTP, il peut avoir des difficultés pour récupérer l’accès à ses comptes
• Phishing : Comme l’OTP, le TOTP n'est pas à l'abri des attaques de phishing. Si un utilisateur est trompé pour qu'il révèle son OTP à un attaquant, ce dernier peut utiliser l'OTP pour accéder au compte.

Silent Network Authentication (SNA)

L’authentification silencieuse permet de valider que la SIM de l’utilisateur est à la fois activement connectée au réseau mobile et n’est pas clonée. La technologie SNA est basée sur le standard authentification GSM.

Voici son fonctionnement général :

‍Étape 1 : Le réseau mobile (également appelé opérateur) active une carte SIM avec une clé d'authentification unique (connue sous le nom de Ki). Cela se produit lorsque l'utilisateur reçoit une nouvelle carte SIM. Les deux parties ont la clé unique, mais elle n'est jamais partagée sur le réseau.

Étape 2 : SNA initie un challenge d'authentification. Le réseau mobile envoie un nombre aléatoire de 128 bits (connu sous le nom de RAND) sur le réseau à la carte SIM. A partir de ce moment là le réseau mobile et la carte SIM ont tous deux connaissance de la clé d'authentification (Ki) et du nombre aléatoire (RAND).

Étape 3 : La carte SIM et le réseau mobile utilisent tous deux Ki et RAND comme entrées d'une *one-way function*. La sortie de la fonction à sens unique est une "réponse signée" (SRES).

Étape 4 : La carte SIM envoie son SRES au réseau mobile.

Étape 5 : Le réseau mobile vérifie que les deux SRES correspondent. S'ils correspondent, l'utilisateur est authentifié. Cette forme de cryptographie à clé symétrique rend très difficile pour un attaquant de falsifier la SRES, ce qui rend cette méthode d'authentification à la fois sécurisée et déterministe. SNA présente un niveau de sécurité similaire avec des applications d'authentification (TOTP) comme Authy ou Google Authenticator.

Remarquez qu'un utilisateur n'a rien à faire ni à fournir d'entrée pour que la carte SIM soit authentifiée - tout se passe en arrière-plan.

Avantages

• Réduire les frictions et la complexité liées à l'utilisation d'un processus d'authentification basé sur SMS ou CAPTCHA pour les clients
• Ne pas obliger les utilisateurs à télécharger une application d'authentification telle que Google ou Microsoft Authenticator
• Éliminer les entrées de formulaire qui peuvent être utilisées pour capturer les informations des utilisateurs

Inconvénients

• Pas utilisable en mode WiFi
• Uniquement disponibles dans certains pays
• Une configuration supplémentaires est nécessaires pour les téléphones avec double SIM

‍

Authentification Push

‍

L'authentification push est une méthode d'authentification à deux facteurs qui utilise un appareil de confiance, généralement un smartphone, pour valider les tentatives de connexion à un compte ou une application. C'est une approche de plus en plus populaire qui offre à la fois un haut niveau de sécurité et une bonne expérience utilisateur.

Lors de la première authentification sur l’application mobile, vous pouvez enregistrer votre appareil comme étant de confiance.

Pour les connections futures, l'expérience varie en fonction de l'appareil que vous utilisez pour vous connecter.

1. Votre appareil : Si vous vous connectez à l'application depuis votre appareil de confiance, aucune authentification à deux facteurs n'est nécessaire. L'application reconnaît votre appareil et vous permet de vous connecter directement.
2. Un autre appareil mobile ou un site web : Si vous tentez de vous connecter à l'application depuis un autre appareil mobile, une notification push est envoyée à votre appareil de confiance. Vous devez accepter cette notification sur votre appareil de confiance pour autoriser la connexion.

Voici son fonctionnement général :

1. Demande d'authentification : Lorsqu'un utilisateur tente de se connecter, une demande d'authentification est envoyée à l'appareil mobile de l'utilisateur.
2. Notification push : L'utilisateur reçoit une notification push sur son appareil mobile. Cette notification indique que quelqu'un (espérons-le, l'utilisateur lui-même) tente de se connecter à son compte.
3. Vérification : L'utilisateur vérifie la demande en appuyant sur un bouton dans la notification, généralement marqué comme "Approuver" ou "Refuser". L'utilisateur peut également être invité à fournir un autre facteur d'authentification, comme une empreinte digitale ou un code PIN, pour approuver la demande.
4. Confirmation : Si l'utilisateur approuve la demande, un signal est envoyé en retour au service demandant l'authentification pour confirmer que l'utilisateur est bien celui qu'il prétend être.

Le passage par un service de push notification (FCM, APNS) n’est pas obligatoire. Un système de pulling peut être mise en place. L’utilisateur doit alors de lui même ouvrir l’application. C’est l’application qui se charge ensuite de savoir si elle doit afficher une modale pour valider une connection ou non. C’est flux est implémenté par exemple par Google à travers l’application youtube ou gmail.

‍

^Avantages

1. Sécurité accrue : Les attaques de phishing sont plus difficiles car l'authentification repose sur un échange de messages entre le serveur d'authentification et l'application mobile, et non sur la saisie d'un mot de passe ou d'un code unique.
2. Meilleure UX : L'utilisateur reçoit une notification et n'a qu'à approuver ou rejeter la demande d'authentification. Cela élimine le besoin de saisir des mots de passe ou des codes uniques.
3. Détection des fraudes : Les utilisateurs sont immédiatement alertés en cas de tentatives d'accès non autorisées à leur compte, car ils reçoivent une notification à chaque demande d'authentification. Un clique sur le bouton refusé doit d’avantage alerté qu’un OTP incorrect qui pourrait être du à une faute de frappe.
4. Pricing : Comme on ne dépend pas d’un opérateur mobile, les coûts sont plus faibles.

Inconvénients

1. Risques liés aux notifications : Les notifications ne sont pas transmises dans 100% des cas. D’autre part, l’utilisateur peut ne pas les voir, soit par inattention, soit à cause de la configuration du téléphone. L'authentification peut alors échouer. La mise en place du système de pulling est donc recommandée en plus du système de push notification.
2. Couverture plus réduite des use cases supportés par rapport à l’OTP:

WebAuthn (iOS PassKey - android FIDO2)

Authentification Web (WebAuthn) est une norme web publiée par le Consortium World Wide Web (W3C). Le but du projet est de standardiser une interface pour authentifier les utilisateurs auprès des applications et services basés sur le web en utilisant la cryptographie à clé publique.

Cette norme a été implémenté coté mobile :

• Pour les applications Android, les développeurs peuvent utiliser l'API FIDO2 d'Android, qui propose des méthodes WebAuthn pour générer et attester des identifiants de clé publique, ainsi que pour s'authentifier avec ces identifiants.
• Pour les applications iOS, Apple a développé la fonctionnalité PassKey, accessible depuis iOS 16 https://developer.apple.com/passkeys/

Passons le jargons technique et regardons comment Payfit utilise cet outil sur iOS pour nous permettre de nous connecter à leur application :

1. L’utilisateur navigue sur le site app.payfit.com et entre son email
2. Au lieu de saisir son mot de passe, l'utilisateur est invité à utiliser son FaceID ou TouchID pour confirmer son identité

Grâce à FaceId, l'utilisateur récupère sa PassKey et l'utilise pour se connecter à Payfit.

Cette PassKey a été créé lors de la création du compte de l’utilisateur, ou lors d’un onboarding post connexion lorsque la feature a été déployé en production comme c’était le cas pour Payfit.La PassKey est soit sauvegardée localement, soit sur un autre appareil Apple synchronisé avec iCloud et est utilisé par l’OS pour confirmer l’identité de l’utilisateur.

Le passkey est accessible et partageable dans paramètres > mot de passe.

Le fonctionnement de WebAuthn est complexe. Pour ne pas rallonger cette newsletter, qui est déjà (avouons le) trop longue, nous invitons les personnes plus curieuses à consulter :

• ce livre blanc https://www.okta.com/sites/default/files/pdf/How_WebAuthn_Works_0.pdf
• ce documentde W3C https://www.w3.org/TR/webauthn-2/

Avantages

1. Sécurité renforcée grâce à l’utilisation d’algorithme cryptographie asymétrique.
2. Résistance au phishing: Étant donné que WebAuthn ne nécessite pas le partage de données d'identification secrètes et garantit que le site web est le même lors de l'enregistrement et de l'authentification, il est résistant à de telles attaques.
3. Authentification sans mot de passe: WebAuthn permet aux utilisateurs de s'authentifier en utilisant des biométriques, des appareils mobiles ou des clés de sécurité FIDO, éliminant ainsi le besoin de mots de passe.
4. Interopérabilité: WebAuthn est une norme web, ce qui signifie qu'elle fournit un standard auquel les différentes plateformes se conforment.

Inconvénients

1. Si votre utilisateur perd son téléphone, qu'il utilise pour l'authentification WebAuthn (biométrie, clé de sécurité, etc.), il ne pourra pas s'authentifier sur votre plateforme jusqu'à ce qu'il retrouve l'accès à son appareil. C'est un inconvénient potentiel de l'authentification forte à deux facteurs, mais il existe plusieurs façons de gérer de telles situations :
2. Codes de secours: Lors de la configuration initiale de l'authentification à deux facteurs, vous pouvez fournir aux utilisateurs des codes de secours. Ces codes peuvent être imprimés ou écrits et stockés en toute sécurité hors ligne. Si un utilisateur perd son appareil, il peut utiliser l'un de ces codes pour s'authentifier.
3. Méthode d'authentification de secours: Permettez à vos utilisateurs de configurer plus d'une méthode d'authentification comme l’OTP ou les magic links.
4. Processus de récupération de compte: Mettez en place un processus de récupération de compte robuste. Cela pourrait impliquer de contacter le support client, de vérifier l'identité par d'autres moyens (comme l'e-mail ou les questions de sécurité), ou même de vérifier les documents d'identité personnelle dans certains cas.
5. Complexité d’implémentation : La mise en œuvre de WebAuthn peut être complexe et nécessite une bonne compréhension de la cryptographie à clé publique et de la norme.
6. “Trop” innovant : Ce système n’est pas adapté à tout les persona. Elle sera mieux accueilli par les early adopters et les technophiles.
7. Compatibilité des OS : Cette technologie est encore très jeune, et disponible seulement à partir d’iOS 16. Elle pourra être adopté à plus grande échelle dans les années à venir.

Magic Link

L'authentification par Magic Link est une méthode d'authentification qui permet aux utilisateurs de se connecter à un compte ou à une application en cliquant sur un lien généré et envoyé par e-mail ou par SMS. Lorsqu'un utilisateur clique sur le Magic Link, il est automatiquement authentifié et accède à son compte en saisissant uniquement son email.

Fonctionnement général

Le fonctionnement est assez similaire à celui de l’authentification OTP :

1. L'utilisateur demande une connexion à l'application en entrant son email
2. L'application génère un MagicLink et le transmet au service d'e-mail ou de SMS.
3. Le service d'e-mail ou de SMS envoie le lien magique à l'utilisateur.
4. L'utilisateur clique sur le lien magique.
5. L'application valide le lien magique et authentifie l'utilisateur.

Avantages

• Simplicité et convivialité pour les utilisateurs.
• Expérience de connexion rapide et sans effort.
• Élimine le besoin de mémoriser et de réinitialiser des mots de passe.
• Facile à mettre en œuvre et à intégrer aux applications existantes.

Inconvénients

• Dépend de la sécurité de l'e-mail ou du numéro de téléphone utilisé pour envoyer le lien magique.
• Risques de sécurité si les Magic Link sont interceptés.
• Un accès non autorisé peut se produire si l'e-mail ou le numéro de téléphone est compromis.
• Peut ne pas être adapté à tous les scénarios, notamment lorsque des niveaux de sécurité plus élevés sont nécessaires ou lorsque des contraintes réglementaires spécifiques sont en place.

Best practices

1. Expiration : Les MagicLink doivent expirer après un certain temps et ne doivent être utilisés qu'une seule fois pour réduire au minimum la fenêtre d’attaque
2. Threshold : pour empêcher un attaquant d'envoyer des demandes de Magic Link en nombre.
3. Authentification à deux facteurs (2FA) : Pensez à ajouter une couche de sécurité supplémentaire, comme la 2FA, surtout pour les actions sensibles dans l'application.

Qu’est-ce que ça donnerait appliqué à un projet BAM ? L’exemple Younited

L’année dernière, BAM a aidé Younited Credit dans le lancement de son application mobile.

Pour rappel, Younited Credit c’est une start-up qui simplifie l’expérience de demande de crédit et aide ses utilisateurs à emprunter très rapidement. Par exemple, si vous venez de faire tomber votre iPhone dernier cri à l’eau et qu’il est grillé ou si vous voulez acheter une voiture parce que vous attendez 2 bébés, Younited vous promet une réponse à votre demande de crédit pratiquement immédiate !

Evidemment, dès que l’on parle de compte en banque et d’emprunt, on s’attend à une authentification bien corsée. Au delà d’un devoir moral, c’est une obligation “marketing” de Younited.

Je ne citerai pas ma stat préférée “en moyenne, un utilisateur gère 100 mots de passe différents et passe 13 minutes PAR SEMAINE à les réinitialiser” (Livre blanc : 7 Things You Need to Know About Passwordless Authentication - Auth0, 2021). Mais elle illustre bien le besoin pour les entreprises de simplifier l’authentification.

On pourrait imaginer que Younited Credit décide de se détacher du mot de passe, et pour son log-in, ne demande que l’adresse email du compte de l’utilisateur. Pour l’authentifier, il pourrait envoyer un email avec un lien expirant à la fin de la session de l’utilisateur.

Ainsi, en arrivant sur l’app, l’utilisateur rentre son adresse email (un identifiant qu’il ne risque pas d’oublier). Cela déclenche l’envoi d’un email. En 3 clics, il y a accès sur son device. Au clic sur le lien, l’utilisateur est redirigé vers l’app via un habile magic link. Celle-ci s’ouvre et il est automatiquement authentifié. Quand il finit sa session sur l’app, il est automatiquement “déconnecté”. Et le lien est désactivé.

L’utilisateur bénéficie d’une expérience sécurisée (en apparence grâce un lien “éphémère” et en réalité), tout en évitant la friction du log-in avec un mot de passe compliqué.

Conclusion

Nous vous encourageons à aller au-delà de la simple authentification par mot de passe et à considérer ces méthodes comme des pistes à explorer dans vos futurs projets. En cherchant des solutions innovantes, nous pourrons offrir à nos utilisateurs une expérience sécurisée et fluide, tout en renforçant la confiance qu'ils placent en nos applications.

N'oublions pas que la sécurité est un enjeu crucial dans le développement d'applications mobiles, et qu'il est de notre responsabilité de rester à jour avec les standards du marché.

‍