Partager les codes Microsoft Authenticator en équipe

Avant de choisir comment partager quoi que ce soit, déterminez laquelle de deux choses différentes votre compte utilise. Microsoft Authenticator fait les deux, et elles ont des réponses opposées.

Si la connexion produit une invite sur un téléphone demandant de recopier un nombre affiché à l’écran, il n’y a rien à partager, par conception, et le remède est du côté des identités. Si elle produit un code à six chiffres qui décompte dans l’application, c’est du TOTP ordinaire, et le remède est de garder le secret à un seul endroit pendant que votre équipe lit les codes.

Deux produits dans une seule application

Les approbations par notification concernent les comptes Microsoft professionnels, scolaires et personnels. Le compte est enregistré sur un appareil ; à la connexion, l’application demande à son détenteur d’approuver et, depuis que la correspondance de nombre est devenue la norme, de saisir un nombre affiché sur l’écran de connexion. Aucun code n’est affiché pour que quelqu’un d’autre le relaie.

Les codes TOTP concernent tout le reste. L’application stocke des secrets standards et affiche six chiffres avec un décompte, exactement comme n’importe quelle autre. Tout ce qui est vrai du TOTP ailleurs l’est ici.

Les équipes s’y perdent parce que les deux vivent derrière la même icône. Un collègue dit « envoie-moi le code d’Authenticator » et, selon le compte, cette demande est soit impossible, soit une mauvaise idée, pour des raisons entièrement différentes.

Pourquoi une approbation par notification ne se partage pas

La correspondance de nombre a supprimé l’ancien contournement. Quand l’application demandait seulement « approuver ou refuser », une personne pouvait appuyer sur approuver pendant qu’un collègue se connectait de n’importe où, et n’importe quel attaquant en possession d’un mot de passe pouvait bombarder d’invites jusqu’à ce que quelqu’un accepte par réflexe. Exiger un nombre lu à l’écran lie l’approbation à celui qui regarde vraiment la page de connexion.

La conséquence pour une équipe, c’est que le téléphone est le facteur. Il n’y a aucune chaîne à copier dans un coffre et aucun code à lire. Quelqu’un peut toujours vous lire le nombre pour que vous approuviez sa connexion, et ça mérite d’être nommé comme une pratique à ne pas normaliser : ça met le détenteur du compte en position d’approuver des invites sur demande, ce qui est exactement le réflexe sur lequel les vraies attaques sont bâties.

Pour ces comptes-là, cessez donc de chercher un mécanisme de partage. Il n’y en a pas, et son absence est la fonctionnalité.

Si c’est un compte Microsoft 365 : réglez les identités

Presque tous les problèmes du type « on doit tous se connecter à ce compte » dans Microsoft 365 ont une réponse qui supprime la connexion partagée. Si les équipes passent à côté, c’est que ces réponses ressemblent à des questions de facturation.

Des comptes par personne. Chacun se connecte en son nom et enregistre son propre appareil dans son propre Authenticator. Les administrateurs gardent un contrôle par utilisateur, et la piste d’audit nomme des personnes plutôt qu’un compte.

Les boîtes aux lettres partagées. Une boîte dans laquelle plusieurs personnes travaillent n’a pas besoin d’un identifiant à elle. L’accès est accordé à des comptes individuels, chacun l’ouvre à côté de son propre courrier, et il n’y a ni mot de passe ni second facteur à distribuer.

L’accès délégué et les groupes. Agendas, sites et adresses de distribution suivent le même schéma : on accorde aux personnes, pas à un identifiant partagé.

Les comptes d’accès d’urgence sont le seul identifiant partagé légitime dans ce tableau. La recommandation de Microsoft est d’en garder un ou deux, tenus hors des politiques habituelles pour qu’un verrouillage d’administrateur reste récupérable. Quoi que vous décidiez pour eux, traitez-les comme une exception documentée, avec des identifiants sous scellés et une surveillance, pas comme le modèle de la façon dont l’équipe marketing accède à un compte.

Si c’est un coût de licence qui a poussé l’équipe vers un identifiant partagé, chiffrez les alternatives avant de l’accepter : les boîtes partagées et la délégation existent en partie pour rendre ça inutile.

Si c’est un code TOTP : les trois options habituelles

Pour les comptes tiers stockés dans l’application (le bureau d’enregistrement, le prestataire de paiement, le tableau de bord client), Microsoft Authenticator n’est qu’une application d’authentification, avec les trois mêmes options que n’importe quelle autre :

1. Un accès par personne sur la plateforme, si elle le propose. Alors rien n’est partagé.
2. Une garde unique du secret, avec un accès par personne aux codes et une trace de qui les a lus.
3. Quelqu’un lit le code à voix haute, ce qui marche jusqu’à ce qu’il soit injoignable.

Les arbitrages sont exposés dans les meilleures façons de gérer la 2FA d’un compte partagé, et le même terrain pour l’autre grande application est dans partager les codes Google Authenticator en équipe. Quels comptes vont dans quel panier : la 2FA d’un compte partagé : comment une équipe devrait-elle s’y prendre ?.

Diagnostiquer ce que vous avez

La dernière ligne mérite d’être vérifiée. Une approbation qui ne demande rien d’autre qu’une pression du doigt, c’est la configuration qui a rendu le bombardement d’invites efficace.

Ce qu’il ne faut pas faire

• Restaurer la sauvegarde de l’application sur le téléphone d’un collègue. Pour les entrées TOTP, ça duplique des secrets définitivement ; pour les comptes Microsoft, ça ne marche même pas comme raccourci.
• Partager un compte Microsoft dans toute l’équipe pour que chacun puisse se servir de son Authenticator. Ça concentre tous les seconds facteurs que vous possédez dans un seul compte, qui réclame alors sa propre protection.
• Capturer le QR code de configuration d’un compte tiers. C’est le secret sous forme visuelle, et le seul moyen de le reprendre est de réinitialiser la 2FA et de réenrôler tout le monde.
• Désactiver la correspondance de nombre pour que les approbations circulent plus facilement. Ça échange un vrai contrôle contre un confort qu’un accès par personne procure proprement.

Où Share Auth se place

Seulement dans la seconde moitié de cet article. Pour les comptes tiers qui n’ont vraiment qu’un identifiant, le secret est saisi une fois et chiffré au repos, les membres invités voient le code et son décompte plutôt que le secret, les permissions sont par membre et par compte, et chaque consultation atterrit dans un journal d’accès.

C’est le rôle d’une application d’authentification partagée, pour les comptes qu’on ne peut pas découper en identités individuelles.

Pour les comptes Microsoft à approbation par notification, il n’y a rien que nous puissions détenir. Le travail, là, consiste à donner à chacun sa propre identité, et c’est une meilleure issue que n’importe quel outil de partage, le nôtre compris.