Aller au contenu

MFA: pour une authentification plus sécurisée

Un rappel sur ce qu'est l'authentification multi-facteur et l'importance de son activation à l'heure où les risques de compromission de compte se multiplient.

Image représentant la sécurité informatique

L'authentification multi-facteur est aujourd'hui le meilleur garde-fou contre la compromission de compte en ajoutant des mécanismes sûrs au sempiternel couple "Login/Mot de passe".

Depuis longtemps, nous nous sommes aperçus que le mot de passe n'était plus une valeur sûre pour authentifier un utilisateur : des mots de passe trop faibles, des bases de données insuffisamment sécurisées, les très récentes failles de sécurité de Gitlab ou le piratage du compte X (ex-Twitter) de la SEC, l'organisme fédéral américain de réglementation de contrôle des marchés financiers, sont autant d'exemples démontrant la faible sécurité apportée par les mots de passe.

Il existe des solutions pour totalement remplacer ces mots de passe, reposant généralement sur l'usage de la cryptographie asymétrique. Mais cela va prendre du temps avant de changer les habitudes des fournisseurs de service ou des utilisateurs. Tant que cette nouvelle pratique ne se sera pas démocratisée, le MFA reste la solution de sécurité par excellence.

Qu'est-ce que le MFA ?

L'authentification multi-facteurs se base sur trois catégories distinctes : 

  • Ce que je sais
  • Ce que je suis
  • Ce que je possède

Le multi-facteurs d'authentification est un mécanisme faisant intervenir au moins deux de ces types. S'il y en a deux seulement, on parlera généralement de 2FA.

Entendons-nous bien : il s'agit de types différents de facteurs et non une récurrence d'un même type. Si vous demandez deux mots de passe différents à un utilisateur, on ne va pas considérer cela comme du multi-facteurs.

Facteur "Ce que je sais"

"Ce que je sais" est déjà le facteur que tout le monde implémente et utilise dans sa vie quotidienne : le mot de passe ou le code PIN.

De manière générale, il s'agit de quelque chose connue seulement de l'utilisateur. Tant que ce dernier ne l'écrit pas sur un post-it collé sous son écran ou le célèbre "4 zéros", bien sûr.

Découvrez d'ailleurs les mots de passe les plus courants dans cet article. Ils représentent une faille de sécurité majeure !

Facteur "Ce que je suis"

"Ce que je suis" regroupe tout ce qu'on appelle "Biométrie".

Il s'agit d'une caractéristique qui vous est propre en tant qu'individu, difficilement falsifiable : empreinte digitale, vocale, rétinienne, votre visage.

Même les vrais jumeaux ont des empreintes digitales distinctes. Et d'après la page Wikipédia sur les empreintes digitales, il y a une chance sur 64 milliards que deux personnes aient les mêmes.

Facteur "Ce que je possède"

Ce dernier type de facteur fait généralement appel à un appareil dont seul l'utilisateur est propriétaire : un téléphone, une clef de sécurité voire une carte à puce.

Le fait de scanner avec son téléphone un QR Code pour obtenir ensuite des codes à 6 chiffres temporaires (TOTP) rentre dans cette catégorie.

Même chose avec l'envoi du code par SMS.

Limitations

Comme tout système de sécurité, le MFA vient avec ses limitations. Aucun système ne pourra être sûr à 100%.

Si vous avez vu le premier film Mission Impossible avec Tom Cruise et Jean Reno, les protagonistes arrivent à accéder à des données sécurisées par mot de passe, empreintes digitales, rétiniennes, vocales, lasers, capteurs audio, …

Oui, bon, ce n'est qu'un film ! Mais cela illustre le propos : il ne faut pas faire totalement confiance à un système de sécurité.

Voici quelques exemples concrets de systèmes faillibles.

Jugé contraignant

Les utilisateurs vont généralement trouver contraignant de devoir s'authentifier avec plusieurs systèmes. Certains systèmes prévoient pour ces utilisateurs la possibilité de "se souvenir" que c'est un appareil sécurisé : Google entre autres. 

Cependant, le confort d'une case à cocher pour se souvenir de l'appareil peut-il compromettre les avantages sécuritaires du MFA ?

Il nous appartiendra, à nous les sachants des technologies informatique, de sensibiliser les utilisateurs moins avertis sur la nécessité de mettre en place et accepter cette contrainte, en attendant que soit généralisée une meilleure solution que le mot de passe.

Le téléphone

Beaucoup de systèmes vont reposer sur la possession d'un smartphone.

Mais le téléphone en lui-même est-il sécurisé ? Si n'importe qui peut déverrouiller une session sur le téléphone portable de la cible, alors quel que soit le système que vous mettrez en place, il ne servira à rien.

Plus technique, pour cibler les codes par SMS, nous avons le SIM swapping : ce sera plus difficile mais c'est une attaque existante permettant à un attaquant de récupérer les SMS d'authentification de sa cible.

La clef de sécurité ou la carte à puce

Lorsqu'on fait appel à un appareil de ces deux types pour du MFA, nous voulons seulement prouver que l'utilisateur est en possession de l'appareil.

Il suffira donc que l'utilisateur cible laisse sa clef ou sa carte traîner pour qu'un attaquant l'utilise.

Les empreintes digitales

N'allez pas croire que vos téléphones incorporent des lecteurs d'empreintes de catégorie militaire. Vous devez déjà expérimenter de temps en temps, lorsque la peau est humide ou souillée, des échecs d'authentification avec votre empreinte.

Pour vous éviter au maximum ce genre d'inconvénient, les lecteurs que vous trouverez sur les smartphones ou tablettes sont volontairement "affaiblis" pour qu'un petit changement ne vienne pas vous bloquer le téléphone.

Et il existe bel et bien des techniques pour brute-force les capteurs d'empreintes digitales dont la copie de l'empreinte digitale de l'utilisateur cible. D'ailleurs, sans vouloir faire la pub, il semblerait que le Touch ID de la marque à la pomme soit bien plus résistant que celui de ses concurrents au petit robot vert.

Mais alors, quelle est la solution ?

Vous êtes développeurs ou CTO d'une application SaaS, je vous laisse une chance de deviner : 

Réponse A : ne rien faire, on va rester sur un simple mot de passe ;

Réponse B : implémenter le protocole WebAuthN et les recommandations de la FIDO Alliance pour se débarrasser définitivement des mots de passe ;

Réponse C : mettre en place le MFA tout de même.

Pour un cas général, la bonne réponse sera la C : vous ne pourrez pas changer les habitudes de vos utilisateurs du jour au lendemain.

La plupart des attaques citées contre les systèmes MFA requièrent que l'attaquant ait un contact plus ou moins direct avec sa cible pour voler sa clef ou son téléphone. À moins d'un coup de malchance énorme de rencontrer un hacker et d'oublier son téléphone non sécurisé sur sa table, le quidam moyen ne sera pas une cible directe : la plupart des attaques seront opportunistes. Il vaut mieux un système imparfait plutôt que l'absence de système.

Pour des utilisateurs avertis et avec une équipe de développeurs chevronnés, vous pourrez opter pour la réponse B et une solution passwordless. 

Gardez tout de même à l'esprit que la plupart des systèmes mettant en oeuvre le WebAuthN auront les mêmes limitations que le MFA à un détail près : en général, l'authentification passwordless est implicitement multi-facteur ; le standard de la FIDO Alliance prévoit la vérification de l'utilisateur (dépendant du système d'authentification mais cela peut être un code PIN ou l'empreinte digitale) avant l'opération cryptographique permettant l'authentification.

Sensibilisation

Dans tous les cas, il faudra passer par une bonne sensibilisation des utilisateurs aux mérites du MFA et de la sécurisation des différents moyens d'authentification.

En tant qu'utilisateur, privilégiez l'activation du MFA ou du 2FA sur les services que vous utilisez.

Et multi-facteur ou non, en cas de suspicion de compromission de son compte, gardez les bons réflexes : changement du mot de passe, changement de la clef de génération des TOTP ou la rotation des clefs asymétriques.

Enfin, une sensibilisation des développeurs sur les bonnes pratiques inhérentes à chacun des systèmes : le verrouillage des codes PIN ou des comptes après des essais infructueux, la vérification de la propriété d'une clef publique par l'utilisateur… Mais là, c'est un autre sujet, peut-être celui d'un prochain article.

Dernier