Notre vie numérique repose sur les mécanisme d'authentification. Grâce à ces derniers, nous pouvons être reconnu sur les services distants où nous nous sommes inscrit afin qu'ils puissent nous mettre nos informations à disposition. Mais lorsque le mécanisme d'authentification, souvent unique, se révèle insuffisant pour empêcher un tiers non-autorisé d'avoir accès à nos données, c'est le drame. Une première solution est de renforcer ce facteur d'authentification, ce qui se traduit bien souvent en la sélection d'un mot de passe robuste. C'est un bon début, mais malheureusement insuffisant : il faut alors penser à multiplier le nombre de ces facteurs.

Qu'est-ce que l'authentification multifacteur ?

L'ensemble des méthodes d'authentification peuvent se répartir dans 3 catégories :

• Ce que l'on sait : il s'agit ici des systèmes d'authentification où l'on nous demande une information que l'on est seul à connaître, par exemple un mot de passe ou un code pin.
• Ce que l'on possède : l'authentification repose sur un élément physique que l'on est seul à détenir, par exemple une carte à puce ou un terminal informatique spécifiquement enrôlé.
• Ce que l'on est : on parle ici de nos caractéristiques propres, en particulier biométriques (empreintes digitales, reconnaissance faciale,…).

L'authentification multifacteur consiste à utiliser au moins deux systèmes d'authentification différents parmi au moins deux catégories différentes. Pour pousser le sujet plus loin, je vous invite à consulter l'excellent guide de l'ANSSI sur l'authentification multifacteur et les mots de passe.

Il existe beaucoup de technique pour faire ça. Actuellement, une des plus répandue est de coupler une authentification par identifiant et mot de passe (ce que l'on sait) avec la fourniture d'un code à usage unique d'une application sur notre téléphone portable (ce que l'on possède). Le standard le plus utilisé pour générer ces codes est TOTP ; souvent nommée « Google Authenticator » du nom d'une vielle application emblématique, parfois « application d'authentification » ou bien d'autres termes similaires.

Je n'aborderai pas WebAuthn/FIDO2/Passkeys qui, bien qu'étant un sujet très intéressant, nécessite qu'on lui consacre bien plus que quelques lignes.

Le code par SMS, oui mais non

Si vous avez lu le guide de l'ANSSI précité, vous avez sans doute remarqué que l'utilisation d'un code à usage unique envoyé par SMS est formellement déconseillé. Les raisons invoquées sont le manque de sécurité des protocoles assurant la transmission des SMS (risque d'interception) ainsi que le risque de SIM Swapping.

Il n'aura pas échappé aux amateurs de sécurité de remarquer que ces techniques nécessitent toutes des moyens non-triviaux ainsi de viser une cible précise afin de pouvoir fonctionner. De plus, le SIM Swapping n'est pas possible chez tous les opérateurs (seulement les moins prudents) ni dans tous les pays (les États-Unis sont largement à la traîne sur ce sujet). Et les résultats s'en font sentir : une étude de Google montre qu'un code à usage unique reçu par SMS a permis de bloquer 100% des attaques entièrement automatisées, 96% des attaques de masse et 76% des attaques ciblées. Dès lors, pourquoi s'en passer si l'on est pas une cible d'intérêt ?

Mais les raisons techniques ne sont pas les seules à prendre en compte, car l'avidité des dirigeants est grande. C'est ainsi que, par le passé, Twitter a vendu à des publicitaires les numéros de téléphones renseignés par ses membres dans le but de recevoir des codes de sécurité. Les SMS représentant un coût, il n'aura donc pas fallu attendre longtemps après cette amende pour que Twitter ne réserve les codes de sécurité par SMS qu'aux seuls abonnés payant. Si vous ne tenez pas particulièrement à voir votre numéro de téléphone figurer dans une base de données de spammeurs, ne le renseignez pas pour obtenir des codes de sécurité. Vous avez mieux à faire avec TOTP.

Le fonctionnement de HOTP et TOTP

Tout d'abord, parlons de HOTP. Il s'agit d'un algorithme qui, à partir d'une clé secrète et d'un compteur, permet de générer un code de vérification. À chaque génération d'un nouveau code, on incrémente le compteur de 1. Pour s'en servir comme second facteur d'authentification, il faut donc que les deux parties disposent de la même clé secrète ainsi que du même compteur. Dans l'éventualité où la partie souhaitant s'authentifier génère par erreur de nouveaux codes qui ne sont pas transmis à l'autre partie, cette dernière peut accepter un nombre défini de codes ayant un numéro de compteur plus élevé que ce qui est attendu et elle met alors à jour son compteur avec ce nouveau nombre. En revanche, elle ne doit jamais accepter de code ayant un numéro de compteur inférieur à ce à quoi elle s'attend car ce serait prendre le risque qu'une personne non autorisée écoutant les échanges rejoue un vieux code qu'elle aurait intercepté.

Ce système (ou des dérivés de fonctionnement similaire) est parfois utilisé pour des clés de voiture ou de garage. On commence par synchroniser la clé avec le portail ou la voiture afin que les deux parties définissent une clé secrète. À chaque appui sur la clé, un code est généré, envoyé par onde radio et le compteur est incrémenté de 1. Lorsque le portail ou la voiture reçoit un signal radio, elle calcule à son tour le code qu'elle attend à partir de sa clé secrète et de son compteur. Si ce code calculé correspond au code reçu, elle ouvre la serrure et incrémente son compteur. Si le code reçu ne correspond pas au code généré, elle peut retenter la comparaison avec d'autre codes générés avec des valeurs plus élevés du compteur. Si l'un d'entre eux correspond, elle ouvre la serrure et met à jour son compteur.

TOTP est une manière très astucieuse d'utiliser HOTP : tout est identique, mais à la place d'utiliser un compteur que les deux parties doivent incrémenter et parfois synchroniser, ce dernier est calculé en fonction de la date et de l'heure. Plus exactement, on prend généralement le reste entier de la division par 30 du nombre de secondes écoulées depuis le 1er janvier 1970 à minuit. Cette méthode permet d'obtenir un compteur qui change toutes les 30 secondes. En conséquent, pour que TOTP fonctionne il faut veiller à ce que les deux parties soient bien à l'heure.

Revenons un peu sur l'enrôlement. Cette étape pourrait se réaliser manuellement en demandant à l'utilisateur d'entrer manuellement la clé secrète dans son application, mais ce procédé est considéré comme trop risqué car l'utilisateur peut faire des erreurs de saisie ou bien copier la clé dans un autre endroit dont la sécurité n'est pas adéquate. Afin d'éviter ça, les applications web proposent le plus souvent un QR code que l'utilisateur scanne à l'aide de son application de gestion des OTP.

Le problème dans tout ça c'est qu'il n'existe à ce jour aucun standard qui régisse ce qu'un tel QR Code doit contenir. Faut-il y mettre directement la clé, et si oui sous quelle forme (binaire, hexadécimale, base 32, base 64,…) ? Et puis, que faire si l'on souhaite utiliser un paramétrage différent de celui par défaut, par exemple utiliser des plages de 45 secondes au lieux de 30 secondes pour TOTP ? C'est pour répondre à cette problématique que Google a défini un format d'URI définissant la manière de passer la clé ainsi que les principaux paramètres. Malheureusement, il ne s'agit pas d'un véritable standard et cette initiative s'inscrivait dans le cadre du développement de l'application Google Authenticator qui a depuis été abandonnée. On l'utilisera quand même, faute de mieux, mais à regret.

Un dernier point : dans les standards, il est prévu que HOTP utilise la fonction de hachage SHA-1 pour dériver les codes à usage unique. TOTP, quant à lui, peut également utiliser SHA-1 mais également SHA-256 et SHA-512. Bien que, dans ce cas d'usage précis, l'utilisation de SHA-1 n'est pas problématique, on peut tout de même préférer l'utilisation d'une fonction de hachage plus sûre. Ceci dit, notez que dans tous les cas il est possible d'utiliser n'importe quelle autre fonction de hachage générique, et ce même si cette dernière n'est pas définie dans le standard.

Qu'attendre d'une application de second facteur d'authentification ?

HOTP et TOTP sont des protocoles plutôt simples à implémenter. Cependant, il est tout de même recommandé de n'utiliser que des applications activement maintenues afin d'au moins pouvoir disposer de mises à jour de sécurité.

Comme pour toute application, surtout celles ayant trait à la sécurité, il est nécessaire d'avoir confiance en l'éditeur. Pour cela, l'utilisation d'une application sous licence libre est très fortement recommandé.

Enfin, faut être en mesure de pouvoir sauvegarder ses données, ce qui nous amène au point suivant.

Synchronisation et sauvegarde

Le truc bien avec la cryptographie c'est que c'est très efficace. Tellement efficace que, si vous perdez un secret, plus personne ne peut rien pour vous, c'est game-over direct et sans recours possible. Du coup, ce serait quand même une bonne idée de ne pas perdre les secrets qui nous sont absolument nécessaire pour nous connecter sur nos différents comptes en ligne.

La vie étant ce qu'elle est, il est probable (mais heureusement pas si fréquent que ça) que votre téléphone soit un jour cassé, volé ou même perdu. En conséquent, s'il y a un risque que vous ne voulez pas prendre, c'est que vos secrets d'authentification soient uniquement stockés sur ce téléphone et donc susceptibles de soudainement disparaître si l'un de ces aléas devait arriver.

Notez également qu'un incendie ou autre catastrophe survenant à votre domicile peut détruire à la fois votre téléphone et l'ensemble des sauvegardes que vous aurez stocké chez vous. Il est donc fortement recommandé de ne pas simplement sauvegarder vos données, mais de les sauvegarder en au moins un point physiquement éloigné du support d'origine.

Bref, vous avez besoin d'une application qui vous aide à sauvegarder vos données, voir carrément à les synchroniser. Si vous choisissez une solution dans le cloud, assurez vous que vos secrets sont correctement chiffrés et que vous avez suffisamment confiance dans le service en question. Assurez-vous que vous que votre compte cloud ne peut pas être soudainement suspendu.

Une dernière chose : n'oubliez pas qu'une sauvegarde qui n'a pas été testée est une sauvegarde qui n'existe pas. J'en ai déjà personnellement fait les frais, ne commettez pas la même erreur.

Comparatif des principales applications mobile

Si le tableau ci-dessous est incomplet, présente des erreurs ou imprécisions, n'hésitez pas à me le signaler par email, matrix ou sur les réseaux sociaux. Je n'ai ni le temps ni les moyens de tout tester en détail.

Ma recommandation personnelle :

• Aegis Authenticator pour les utilisateurs sur Android en mesure de mettre en place leur propre stratégie de sauvegarde ;
• 2FA Authenticator pour les autres ;
• FreeOTP est une alternative intéressante.

Application	Distribution	Licence	Statut	Sauvegarde
2FA Authenticator	Google Play Apple Store	GPL 3.0	Actif	Google Drive iCloud Fichier
Aegis Authenticator	F-Droid Google Play	GPL 3.0	Actif	Auto-hébergé Google Drive Fichier
andOTP	F-Droid Google Play	MIT	Abandonné	Fichier
Auth Token	F-Droid	GPL 3.0	Abandonné	Aucune
Authenticator+	Apple Store	Privatrice	Actif	Inconnue
Authenticator Plus	Google Play	Privatrice	Abandonné	Google Drive Dropbox
Dashlane Authenticator	Google Play Apple Store	Privatrice	Actif	Cloud
DuOTP	F-Droid	GPL 3.0	Abandonné	Cloud
FreeOTP	F-Droid Google Play Apple Store	Apache-2.0	Actif	Google Drive Fichier
FreeOTP+	F-Droid Google Play	Apache-2.0	Actif	Fichier
Google Authenticator	Google Play Apple Store	Privatrice	Actif	Inconnue
KeePassDX	F-Droid Google Play	GPL 3.0	Actif	Google Drive Fichier
Microsoft Authenticator	Google Play Apple Store	Privatrice	Actif	Microsoft Account iCloud
OTP Authenticator	F-Droid	MIT	Abandonné	Inconnue
Secur	F-Droid	MIT	Abandonné	Inconnue
TOTP Authenticator	Google Play Apple Store	Privatrice	Peu actif	Google Drive
Twilio Authy	Google Play Apple Store	Privatrice	Actif	Cloud