L’application Google Authenticator est-elle irremplaçable ?

De nombreux services en ligne vous permettent de (et parfois vous obligent à) configurer une authentification à deux facteurs (2FA) avec des codes à usage unique. Google Authenticator est l’application d’authentification la plus connue et la plus utilisée lorsqu’il s’agit de générer ces codes. Presque tous les services sont compatibles avec cette application, et certains fournissent même un lien qui ouvre l’application lorsque vous configurez la 2FA. L’application Google Authenticator est-elle la seule option? Devriez-vous essayer une des autres alternatives, comme Microsoft Authenticator ou Twilio Authy ?

Étant donné que ces services existent et qu’ils comptent quelques utilisateurs, vous pourriez croire qu’ils sont effectivement une solution pour remplacer Google Authenticator. Quels sont, le cas échéant, les dangers ? Pour ceux qui n’ont pas le temps de lire tout l’article, voilà ce qu’il faut en retenir : ne vous inquiétez pas, Google Authenticator est plus que remplaçable. Vous voulez savoir pourquoi, quand et comment ?! Continuez à lire…

Le fonctionnement des applications d’authentification

Commençons par voir comment les applications d’authentification fonctionnent de manière générale. Plusieurs normes ouvertes ont été créés sous l’égide de l’Initiative for Open Authentication (OATH) pour une authentification forte. Les applications d’authentification reposent sur ces normes (ainsi que sur d’autres éléments, mais ce n’est pas l’objet de cet article).

La norme HOTP de l’OATH

Nous revoilà en 2005 lorsque la norme d’authentification OATH HOTP (mot de passe à usage unique basé sur le hachage) a fait son apparition. Cela a posé les fondements de l’authentification à l’aide de codes à usage unique générés par le client et le serveur.

L’idée est que l’application et le service que vous utilisez se souvienne de la même clé secrète. Ensuite, un algorithme de chiffrement s’applique afin de générer un code unique basé sur cette clé et sur une valeur du compteur. Le compteur est simplement un nombre qui augmente à chaque fois qu’un nouveau code à usage unique est généré. Les données utilisées pour calculer ce code sont les mêmes des deux côtés donc, si tout se passe comme prévu, les deux codes devraient être identiques. Il ne reste plus qu’à les comparer : si le code que vous saisissez correspond à celui généré par le serveur, l’authentification est réussie.

Après chaque demande de génération, la valeur du compteur change pour que le code soit unique et ne puisse être utilisé qu’une seule fois. L’algorithme est utilisé pour éliminer les calculs inverses et empêcher que l’on puisse extraire la clé secrète du code. Même si quelqu’un intercepte le code à usage unique, il ne pourra pas calculer la clé secrète, reproduire l’authentificateur et générer son propre nouveau code.

L’HOTP pose principalement deux problèmes. Tout d’abord, les valeurs du compteur échappent facilement à la synchronisation. Par exemple, si vous demandez à l’application de générer un code mais que vous ne l’utilisez pas, l’authentificateur du client change la valeur du compteur alors qu’elle reste la même du côté du service. Par conséquent, les codes générés ne correspondent plus. Ensuite, le code est valable jusqu’à ce que la valeur du compteur change, ce qui pourrait laisser suffisamment de temps aux cybercriminels pour utiliser le code intercepté s’ils arrivent à distraire la victime d’une quelconque façon.

La norme TOTP de l’OATH

Une nouvelle norme a vu le jour en 2011 : OATH TOTP (mot de passe à usage unique basé sur le temps). Cette dernière utilise le temps qui s’écoule comme compteur. Le principe reste le même : une clé secrète que les deux parties connaissent est utilisée pour calculer un code à usage unique avec le même algorithme de chiffrement. Étant donné que ce compteur repose sur l’heure Unix, le code change automatiquement à des intervalles réguliers, qu’il soit utilisé ou non.

N’importe quel appareil connecté à Internet connaît l’heure exacte donc il n’y a pas à s’inquiéter du manque de synchronisation des codes à usage unique. De plus, comme le temps qui s’écoule avant que le code ne change est assez court (30 secondes par défaut), si un code à usage unique venait à être intercepté, les cybercriminels n’auraient pas beaucoup de temps pour l’utiliser.

Les principes de base de l’authentification

Les applications d’authentification utilisent ces deux normes. L’algorithme TOTP est évidemment le plus courant, tout simplement parce qu’il est meilleur, mais l’algorithme HOTP est encore utilisé dans certaines implémentations préhistoriques.

Lorsqu’une application d’authentification est créée, le client et le serveur doivent établir une norme commune et partager la clé. C’est le strict minimum nécessaire pour que l’application d’authentification fonctionne. D’autres paramètres peuvent être établis pour créer les jetons. Comment l’application et le service arrivent-ils à un accord ? Dans la plupart des cas, grâce à un QR code. Ce constat soulève une nouvelle question : comment ces codes fonctionnent-ils ?

Le contenu du QR code de l’application d’authentification

Pour autant que je sache, cela ne fait partie des normes développées par l’OATH. Il s’agit plutôt d’une adhésion volontaire au format établi par Google Authenticator. Quoi qu’il en soit, les systèmes d’authentification basés sur une application utilisent généralement les QR codes qui ouvrent un lien (à proprement parler un Uniform Resource Identifier, ou URI) qui contient toutes les informations nécessaires chiffrées. Voici un exemple :

otpauth://totp/Google:alanna@gmail.com?secret=IN2XE2LPOVZSYIDBOJSW4J3UEB4W65J7&issuer=Google&algorithm=SHA1&digits=6&period=30

Comme vous pouvez le voir, toute une série de paramètres sont communiqués par le QR code, dont les renseignements suivants :

• L’objectif de l’URI. La création d’un jeton d’authentification, qui correspond au mot otpauth au début du code.
• La norme d’authentification, HOTP ou TOTP. Dans ce cas, il s’agit de l’algorithme TOTP.
• L’étiquette du jeton à afficher dans l’application. Google dans cet exemple.
• Le nom d’utilisateur, qui est alanna@gmail.com.
• La clé secrète à partir de laquelle les codes sont générées en format Base32. C’est la partie la plus importante, une longue série de caractères choisis au hasard.
• Le nom du service qui a créé l’URI. Là encore, il s’agit de Google.
• L’algorithme utilisé pour générer les codes. Dans ce cas, SHA-1.
• La longueur des codes générés. Il s’agit généralement de 6 chiffres, comme dans cet exemple, mais d’autres possibilités sont acceptées.
• La durée de validité avant que le code n’expire. Le temps habituel est de 30 secondes, mais d’autres intervalles sont possibles.

Voici à quoi ressemble le QR code correspondant :

Les QR codes peuvent partager toute une série de paramètres pour un jeton d’authentification

En réalité, comme nous l’avons mentionné auparavant, la plupart de ces paramètres peuvent être omis. L’étiquette du jeton et le nom d’utilisateur peuvent être arbitraires, alors que le nom du service n’est pas du tout requis puisque cette information n’a aucun effet sur la génération du code et n’est présente que pour une question de commodité. D’autres paramètres ne sont pas non plus obligatoires. L’authentificateur utilise l’algorithme de génération de code par défaut (SHA-1) et produit un code à six chiffres qui change toutes les 30 secondes, sauf s’il est chiffré différemment par l’URI.

Sur le fond, le service et l’authentificateur n’ont qu’à définir la norme utilisée (HOTP ou TOTP) puis partager la clé secrète. Ainsi, sur le plan fonctionnel, cet autre URI et ce QR code génèrent exactement le même jeton d’authentification que la paire précédente :

otpauth://totp/Whenever:Wherever?secret=IN2XE2LPOVZSYIDBOJSW4J3UEB4W65J7

De nombreux paramètres du QR code peuvent être omis ou établis de façon arbitraire. Le principal est de partager la clé secrète et d’établir une norme (HOTP ou TOTP)

Tout cela pour dire que la plupart des services qui utilisent des codes générés par une application pour l’authentification se servent de ce genre de QR codes. Ensuite, n’importe quelle application d’authentification peut lire les QR codes et les convertir en jetons d’authentification qui, à leur tour, génèrent les codes à usage unique. Ainsi, vous pouvez choisir parmi des dizaines d’applications si vous ne voulez pas utiliser Google Authenticator et opter pour celle qui vous plaît.

Quelques exceptions : certains services ne sont pas compatibles avec les authentificateurs habituels

Pour une raison qui m’échappe, tout le monde dans le monde de l’informatique ne suit pas les normes ci-dessus : certains préfèrent inventer les-leurs. Voici quelques entreprises dont les services et programmes ne sont pas compatibles avec les applications d’authentification tierces (y compris Google Authenticator) :

• Apple. Les gens de Cupertino ont leur propre système 2FA, et il n’utilise aucune application tierce. Les codes à usage unique sont générés par le système d’exploitation en même temps sur tous les dispositifs associés à l’identifiant Apple. C’est comme ça que leur système fonctionne !
• Valve et Blizzard. Pour garantir la sécurité sur Steam et Battle.net, les développeurs proposent leur propre création 2FA : Steam Guard (intégrée dans les versions Android et iOS des applications Steam) et Battle.net Authenticator. Autant que je sache, une seule application d’authentification tierce est compatible avec ces systèmes : WinAuth.
• Microsoft. Pour l’authentification des comptes Microsoft, vous devez installer Microsoft Authenticator. L’avantage c’est que vous n’avez pas besoin de saisir les codes : il vous suffit de confirmer la connexion en appuyant sur un bouton dans l’application. Comme bonus, Microsoft Authenticator génère aussi des jetons d’authentification standards, ce qui en fait une très bonne alternative à Google Authenticator. D’ailleurs, vous n’avez pas besoin d’avoir un compte Microsoft pour vous en servir.
• Adobe. Les développeurs de logiciels graphiques proposent leur propre application 2FA, Adobe Account Access, qui fonctionne de la même façon que Microsoft Authenticator : la connexion à votre compte Adobe est authentifiée lorsque vous appuyez sur un bouton, et non via l’envoi d’un code. En théorie, l’application est aussi compatible avec la création de jetons pour s’authentifier à des services tiers. Pourtant, pour que le système Adobe Account Access fonctionne, vous devez d’abord associer l’application à votre compte Adobe ce qui, selon les avis laissés sur l’App Store et Google Play, n’est pas conseillé.

Dois-je utiliser Google Authenticator ?

Pas forcément. Tous les services qui fonctionnent avec Google Authenticator vous laisseront configurer l’authentification à deux facteurs en utilisant n’importe quelle autre application. De plus, beaucoup d’entre elles ont d’importants avantages sur la création de Google.

D’ailleurs, nous avons publié un article sur les meilleures applications d’authentification pour chaque système d’exploitation les plus courants : Android, iOS, Windows et macOS. Enfin, si vous avez déjà lu cet article dans sa totalité, alors quelque chose nous dit que les applications andOTP (pour Android) et OTP auth (pour iOS) pourraient vous intéresser.