Aujourd’hui, on se retrouve pour tester ensemble une clef FIDO2 sur un environnement Microsoft Cloud. Fini les galères des mots de passe, place à une sécurité renforcée et simplifiée. Dans cet article, je vous partage mon expérience, étape par étape, de la configuration sur un tenant Microsoft à la vérification des connexions via USB et NFC. Venez découvrir comment, avec une approche à la fois technique et accessible, on peut repenser la manière de sécuriser nos identités en ligne.
Qu’est-ce que FIDO ?
FIDO, qui signifie Fast IDentity Online, désigne un ensemble de normes d’authentification qui utilisent la cryptographie à clé publique pour se passer des mots de passe traditionnels.
Concrètement, l’objectif de FIDO est de renforcer la sécurité en ligne en utilisant des méthodes d’authentification plus fiables et ergonomiques, comme les dispositifs matériels (clés de sécurité) ou l’authentification biométrique (empreintes digitales, reconnaissance faciale).
Pour moi, c’est une approche qui simplifie l’expérience utilisateur car, tout en augmentant considérablement la sécurité, ces passkeys sont interopérables, ce qui signifie qu’une seule passkey peut être utilisée sur plusieurs sites ou comptes.
D’ailleurs, j’avais déjà parlé de l’intégration d’une authentification FIDO2 pour le service Azure Virtual Desktop juste ici :
Qu’est-ce que l’Alliance FIDO ?
Créée en 2012, FIDO Alliance est une association d’entreprises du secteur technologique ayant pour objectif de changer la manière dont nous nous authentifions en ligne. L’idée de ce consortium est de se passer des mots de passe, souvent vulnérables, en favorisant des méthodes d’authentification plus sûres et plus simples à utiliser :
Pour résumer, FIDO Alliance réunit de nombreux acteurs du secteur (comme Google, Microsoft, mais pas que) pour développer des standards ouverts, tels que FIDO U2F et FIDO2, qui permettent par exemple d’utiliser des dispositifs matériels (clefs de sécurité) ou des méthodes biométriques pour s’authentifier.
FIDO vs U2F vs FIDO2 ?
Le protocole FIDO original, alias FIDO 1.0, était la première itération de la norme d’authentification FIDO. Publié en 2014, il visait à remplacer les mots de passe traditionnels par des données biométriques et des jetons matériels. Elle comportait à la fois FIDO UAF (Universal Authentication Framework) et FIDO U2F (Universal Second Factor).
En 2016, le World Wide Web Consortium (W3C) et la FIDO Alliance ont commencé à collaborer pour normaliser l’authentification FIDO. Cela a conduit au lancement de FIDO2 en 2018, qui offre une approche plus complète et standardisée de l’authentification sans mot de passe. De nombreux navigateurs célèbres, dont Firefox et Chrome, ont mis en œuvre la norme, ce qui a contribué à son adoption.
FIDO2 a deux composantes principales : WebAuthn et CTAP (Client to Authenticator Protocol). Ensemble, WebAuthn et CTAP offrent une expérience de connexion cryptographiquement sécurisée, pratique et interopérable.
En résumé, les principales différences entre FIDO 1.0 et FIDO2 sont la normalisation, la portée, l’interopérabilité et l’adoption. FIDO2 est un protocole plus complet et normalisé qui est pris en charge par tous les principaux navigateurs et systèmes d’exploitation, y compris Android, IOS, MacOS et Windows.
FIDO2.1 est une petite évolution de la spécification FIDO2 qui vise à combler certaines limites et à renforcer à la fois la sécurité et l’expérience utilisateur. Concrètement, FIDO2.1 apporte notamment :
Une gestion améliorée des PIN et des mécanismes d’authentification locales, avec des règles plus strictes pour éviter les codes trop faibles.
Des processus d’enrôlement et de récupération des identifiants optimisés, pour faciliter la réinitialisation ou le transfert sécurisé des clés.
Une meilleure interopérabilité entre les différents types d’authentificateur (qu’ils soient matériels ou intégrés à un appareil), ce qui simplifie leur déploiement dans des environnements hétérogènes.
En résumé, il ne s’agit pas d’un changement radical, mais plutôt d’un raffinement qui permet d’offrir une sécurité renforcée tout en rendant l’usage du système encore plus fluide et adaptable.
Quelles sont les méthodes de connexion d’une clef FIDO2 ?
USB-A et USB-C :
Pour les PC, on branche la clé directement dans un port USB-A ou USB-C.
Pour les smartphones, il est souvent possible de les utiliser via un câble OTG ou directement sur un port USB-C, selon le modèle.
NFC :
De nombreuses clés intègrent une puce NFC, ce qui permet une connexion sans contact avec des smartphones compatibles (par exemple, iPhone à partir d’iOS 13.3 et de nombreux appareils Android).
À noter toutefois que sur Android, les clés protégées par PIN ne supportent pas la connexion NFC.
La prise en charge des clés de passage de FIDO2.1 (à savoir les clés résidentes protégées par un code PIN) a été introduite dans le cadre de Google Play Services v23 et uniquement par le biais de la méthode de transport USB. Cela signifie donc que :
Android ne prend en charge les identifiants FIDO protégés par un code PIN que si Google Play Services est présent. Android ne prend pas en charge les informations d’identification FIDO protégées par un code PIN via NFC.
Quels sont les risques encourus si je perds ma clef FIDO2 ?
La perte de votre clé FIDO2 peut poser des problèmes d’accès à vos comptes, mais les risques de compromission sont fortement limités. En effet, ces clés reposent sur la cryptographie asymétrique : même si quelqu’un mettait la main sur votre clé, il ne pourrait pas extraire la clé privée qui reste protégée.
De plus, la plupart des dispositifs FIDO2 nécessitent un code PIN ou une authentification biométrique pour être utilisés, ce qui ajoute une couche de sécurité supplémentaire.
Néanmoins, il est important de prévoir une solution de secours. Par exemple, en enregistrant plusieurs clés ou en activant d’autres méthodes de récupération, vous pourrez rapidement révoquer une clé perdue et en associer une nouvelle, sans compromettre l’accès à vos comptes.
Dois-je acheter une licence payante d’Entra ID pour utiliser une clef FIDO2 ?
Non, il n’est pas nécessaire d’acheter une licence Entra ID spécifique pour utiliser une clé FIDO2 en authentification sans mot de passe.
Cette fonctionnalité est incluse dans toutes les éditions d’Entra ID, y compris la version gratuite, même si certaines fonctionnalités avancées (comme l’accès conditionnel) nécessitent des licences Entra ID Premium.
Qui sont Token2 ?
La société Token2 a vu le jour en 2014. Il s’agit d’une entreprise suisse spécialisée dans la cybersécurité, et plus précisément dans l’authentification multifactorielle.
Le siège de Token2 se situe à Versoix, dans la République et le Canton de Genève, en Suisse.
Pour faire simple, ils conçoivent et développent des solutions matérielles et logicielles qui rendent l’authentification en ligne à la fois plus sûre et plus pratique.
D’ailleurs, Token2 est aussi un membre certifié de l’alliance FIDO :
Token2, fier membre de l’Alliance FIDO, a obtenu son certificat FIDO initial en 2019 et fournit une variété de clés de sécurité FIDO depuis plus de 5 ans.
En plus des clés FIDO2 ordinaires, Token2 est ravie de présenter sa très attendue série PIN+, une ligne révolutionnaire de clés de sécurité FIDO2 qui a récemment reçu la certification de l’Alliance FIDO.
Ces clés de sécurité de pointe introduisent des règles avancées de complexité du code PIN qui redéfinissent les standards de sécurité.
Pour aller toujours plus loin dans la sécurité de leurs produits, Token2 a également fait l’objet d’un audit indépendant (réalisé par Compass) en 2024 sur le firmware open source (disponible sur GitHub) de leurs clés Token2 PIN+ (voir leur outil de test de PIN), confirmant leur robustesse et leur transparence.
Enfin, j’en profite pour dire un grand merci à Manon, Emin et Naila pour me permettre de tester vos produits !
Ce qui m’a séduit d’emblée sur cette clef FIDO2.1 R3, c’est la présence du triple combo USB-A, USB-C et NFC, ainsi que le support des normes FIDO et FIDO2.1( avec le support d’OpenPGP et d’OTP) :
Maintenant, il nous reste plus qu’à tester tout cela 😎💪
Etape 0 – Rappel des prérequis :
Pour réaliser nos tests sur une clef FIDO2.1, il vous faudra disposer de :
Un tenant Microsoft
J’ai choisi dans la première partie de l’article de tester la mise en place d’une clef FIDO2 sur un tenant ne disposant d’aucune licence Entra ID Premium.
Pour vérifier si votre tenant dispose de licences ou non Entra ID Premium, je vous propose de commencer par vérifier cette information
Etape I – Configuration du tenant :
Allez dans la page suivante d’Entra afin de constater la présence, ou non, de licences Entra Premium sur votre tenant :
Ensuite, basculez l’onglet des propriétés afin de déterminer la méthode de sécurité appliquée sur votre tenant :
Enfin, vérifiez l’activation, ou non, de différentes méthodes d’authentification sur cette page :
Notre environnement est donc dans sa configuration la plus basique. Avant de modifier celle-ci, je vous propose de constater les méthodes de sécurité déjà disponibles sur notre utilisateur.
Etape II – Ajout de la méthode d’authentification FIDO2 :
Pour cela, rendez-vous sur la page suivante de votre utilisateur, puis cliquez sur le bouton suivant :
Cliquez-ici pour ajouter une nouvelle méthode d’authentification :
Constatez la liste des méthodes d’authentification déjà accessibles à votre utilisateur :
Retournez sur la page des méthodes d’authentification Entra ID via cette page, puis cliquez-ici :
Activez la méthode FIDO2 :
Configurez au besoin les options de cette méthode, puis cliquez sur Sauvegarder :
Vérifiez le changement de statut pour cette méthode d’authentification :
Attendez environ 5 à 10 minutes avant de continuer la configuration de votre utilisateur.
Etape III – Ajout de la première clef FIDO2 :
Retournez sur la page suivante de gestion de compte de votre utilisateur, puis cliquez à nouveau sur le bouton suivant :
Cliquez-ici pour ajouter une nouvelle méthode d’authentification :
Constatez l’apparition de nouvelles méthodes dans la liste de celles disponibles pour votre utilisateur :
Sélectionnez la méthode appelée Clef de sécurité :
Avant cela, Microsoft souhaite vérifier votre identité par une autre méthode MFA déjà en place, cliquez donc sur Suivant :
Réussissez le challenge MFA avec Microsoft Authenticator :
Une fois réussi, recommencez le processus d’ajout, puis cliquez-ici :
Cliquez sur Suivant :
Microsoft communique alors avec votre OS Windows afin de vérifier et d’enrôler la clef FIDO2 :
Attendez encore quelques secondes :
Confirmez les informations de compte, puis cliquez sur OK :
Cliquez sur OK :
Saisissez le code PIN déjà configuré sur votre clef FIDO2, puis cliquez sur OK :
Touchez physiquement la zone prévue à cet effet pour terminer :
Windows confirme le bon enrôlement de la clef FIDO2 chez Microsoft, cliquez sur OK :
Nommez votre clef FIDO2 afin de l’identifier par la suite plus facilement, puis cliquez sur Suivant :
Cliquez sur Terminer :
Constatez l’apparition de celle-ci dans les informations de sécurité de votre utilisateur :
Il est très fortement conseillé d’enrôler toujours 2 clefs afin d’utiliser la seconde en cas de secours.
Testons maintenant comment l’expérience utilisateur est impactée par l’ajout de cette méthode d’authentification FIDO2.
Etape IV – Test de connexion FIDO2 sur PC :
Sur votre poste, ouvrez un navigateur internet en session privée :
Au lieu de saisir le mot de passe de votre utilisateur, cliquez comme ceci :
Attendez quelques secondes :
Renseignez le code PIN de votre clef FIDO2 :
Touchez la zone prévue à cet effet pour confirmer l’authentification :
Cliquez sur Oui :
Et vous voilà correctement authentifié sur le portail de Microsoft Office 365 :
Nous avons vu l’impact de l’authentification d’une clef FIDO2 pour un compte Cloud de Microsoft. Intéressons-nous maintenant à la nouvelle clef FIDO2 proposée par Token2 et ses différentes possibilités d’authentification.
Etape V – Ajout de la clef FIDO2 Token2 T2F2-Dual:
avant d’utiliser cette nouvelle clef FIDO2 pour un compte, il est nécessaire de lui configurer un code PIN.
Pour cela, rendez-vous dans le menu suivant des paramètres Windows :
Cliquez sur le bouton Gérer :
Touchez la zone prévue à cet effet de votre nouvelle clef FIDO2 :
Cliquez-ici pour configurer le code PIN :
Testez un code PIN simple à 4 caractères afin de constater le refus de la nouvelle clef FIDO2 d’accepter cette valeur trop courte :
Testez un code PIN reprenant une simple suite de chiffres à 6 caractères afin de constater un second refus pour accepter cette valeur trop simple :
Renseignez cette fois 6 caractères aléatoires afin de constater l’acceptation de la valeur complexe :
Si nécessaire, il vous est toujours possible de changer ce code PIN en cliquant ici :
Il vous sera demandé de renseigner l’ancien code PIN avant de pouvoir en configurer un nouveau dans le but de conserver les identités déjà configurées :
Retournez sur la page suivante de gestion de compte de votre utilisateur, puis cliquez sur le bouton suivant :
Cliquez-ici pour ajouter une nouvelle méthode d’authentification :
Sélectionnez à nouveau Clef de sécurité, puis repassez sur toutes les étapes afin que votre nouvelle clef FIDO2 apparaisse dans la liste de ses méthodes d’authentification :
Notre nouvelle clef FIDO2 est maintenant en place pour notre utilisateur.
Comme sa méthode d’authentification via le port USB est la même que pour la première clef, testons directement la possibilité de connexion via NFC depuis un smartphone.
Etape VI – Test de connexion NFC sur smartphone :
Si votre smartphone vous permet une connexion via NFC : ouvrez un navigateur internet en session privée, puis rendez-vous sur la page officielle de Microsoft office :
Saisissez le compte de votre utilisateur, puis cliquez sur Suivant :
Sans même saisir son mot de passe, choisissez une méthode d’authentification par une clef de sécurité externe :
Le message suivant vous invite à rapprocher ou à connecter votre clef FIDO2 à votre smartphone :
Dans le cadre du NFC, approchez votre clef de sécurité FIDO2 en haut de votre smartphone comme ceci :
Retirez la clef, puis saisissez le code PIN de votre clef FIDO2 :
Le message suivant vous invite à rapprocher à nouveau votre clef FIDO2 à votre smartphone :
Rapprochez une seconde fois votre clef FIDO2 afin de confirmer l’authentification de votre compte, puis cliquez sur Oui :
Constatez la bonne connexion de votre utilisateur aux services de Microsoft :
Comme annoncé plus haut, certains smartphones de la marque Android ne permettent pas la connexion NFC à votre compte dans le cadre d’une clef FIDO2 protégée par un code PIN.
Etape VII – Test de connexion USB-C sur smartphone :
Si votre smartphone ne vous permet pas la connexion via NFC : ouvrez un navigateur internet en session privée, rendez-vous sur la page officielle de Microsoft office, saisissez le nom de compte, puis cliquez sur Suivant :
Sans même saisir de mot de passe, choisissez une méthode d’authentification par une clef de sécurité externe :
Cliquez sur le bouton ci-dessous :
Le message suivant vous invite à connecter votre clef FIDO2 à votre smartphone :
Connectez votre clef de sécurité FIDO2 via USB-C, puis saisissez le code PIN de celle-ci :
Touchez physiquement la zone prévue à cet effet pour terminer :
Cliquez sur Oui :
Constatez la bonne connexion de votre utilisateur aux services de Microsoft :
Etape VIII – Ajout d’un accès conditionnel FIDO2 :
Depuis votre portail Entra ID, rendez-vous dans le paramétrage des Accès conditionnels afin de constater le besoin de licence Entra ID Premium pour activer cette fonction :
Achetez une licence Entra ID Premium ou basculez sur un tenant en disposant déjà :
Vérifiez que la sécurité par défaut de votre tenant est désactivée au profit de l’accès conditionnel :
Cliquez sur Méthodes d’authentification renforcées pour en ajouter une nouvelle :
Configurez celle-ci :
Puis créez votre nouvelle Police d’accès conditionnel :
Saisissez un nom à votre police, sélectionnez votre utilisateur de test, ajoutez l’application Azure, puis cliquez ici :
Autorisez l’accès sous réserve de satisfaire votre méthode d’authentification renforcée :
Ajoutez si besoin une fréquence d’authentification, puis créez votre police d’accès conditionnel :
Attendez quelques minutes, ouvrez un navigateur internet en session privée, puis rendez-vous sur la page officielle de Microsoft office :
Saisissez le nom et le mot de passe de votre compte de test, puis cliquez comme ceci :
Vous voilà correctement authentifié sur le portail de Microsoft Office 365 :
Toujours en navigation privée, ouvrez un nouvel onglet pour vous rendre sur le portail Azure, puis constatez le besoin d’un complément d’authentification FIDO2 :
Saisissez le code PIN de votre clef FIDO2 :
Touchez votre clé FIDO2 sur la zone prévue à cet effet :
Vous voilà correctement authentifié sur le portail Azure :
Avant de conclure cet article, je trouvais intéressant de parler de certains outils très pratiques et mis à disposition par Token2 sur leur site.
Celui-ci vous permet de tester en direct l’enregistrement et l’authentification via des clés FIDO2 et passkeys. Concrètement, il offre une expérience pratique pour :
Enregistrement (Registration) : Vous pouvez inscrire votre clé de sécurité (physique ou intégrée, c’est-à-dire un authentificateur de plateforme) en utilisant l’API WebAuthn. Lorsque la clé clignote, il suffit de toucher le bouton, scanner l’empreinte ou utiliser le NFC (pour les appareils compatibles) pour finaliser l’inscription.
Authentification (Login) : Une fois la clé enregistrée, l’outil simule un processus de connexion sécurisé. Vous pouvez tester différentes configurations de demande de PIN (toujours, si un PIN est défini, ou jamais) pour voir comment cela influence le comportement de l’authentification.
L’outil fido2-manage est un utilitaire de gestion pour les clés de sécurité conformes à la norme FIDO2.1. Concrètement, il permet de :
Lister les dispositifs connectés : Afficher la liste des clés FIDO2.1 détectées.
Afficher des informations détaillées : Consulter les données techniques de la clé (modèle, AAGUID, certificats d’attestation, etc.).
Gérer les passkeys : Visualiser et supprimer les clés résidentes (passkeys) stockées sur l’appareil.
Configurer ou modifier le PIN : Définir, changer ou forcer une modification du code PIN de la clé.
Réinitialiser la clé : Effectuer une réinitialisation aux paramètres d’usine (en notant que cette opération est possible uniquement dans un court laps de temps après la connexion).
Conclusion
En fin de compte, cette aventure avec la clef FIDO2, notamment la PIN+ Dual Release3, m’a prouvé que la sécurité peut être à la fois robuste et intuitive. Que ce soit pour se connecter via USB ou NFC, l’expérience utilisateur reste fluide et rassurante.
Tester ces solutions, c’est un peu comme prendre un virage vers l’avenir de l’authentification : simple, efficace et sans prise de tête.
Merci d’avoir suivi ce test avec moi, et à très bientôt pour de nouvelles explorations tech !
D’abord, un grand merci à Merill Fernando pour ses newsletters toujours intéressantes sur Entra, dont voici le lien. Beaucoup d’articles écrits sur ce blog proviennent de différentes sources en anglais, et dont les travaux et réflexions méritent des tests et une retranscription en français. J’ai toujours du plaisir à essayer de comprendre certains types d’attaque visant le Cloud. Je voulais donc partager avec vous un exemple basé sur du phishing et dont la mise en place est d’une grande simplicité
Attention, ce contenu a une vocation strictement éducative. Les techniques et démonstrations présentées ici sont destinées à sensibiliser aux enjeux de la sécurité informatique et à permettre de mieux comprendre les mécanismes d’attaque afin de mieux s’en protéger.
Il ne s’agit en aucun cas d’un incitatif à la réalisation d’actions malveillantes. Nous vous encourageons vivement à rester dans un cadre légal et à utiliser ces informations uniquement pour renforcer la sécurité de vos systèmes. Je décline toute responsabilité quant à l’utilisation abusive de ces connaissances.
Un précédent article décrivant un autre scénario d’attaque, via le Device Code Flow, est disponible juste ici. Plusieurs sources m’ont aidé à écrire ce nouvel article :
zolder.io ont créé une application fonctionnant sur un Cloudflare Worker qui agit comme un proxy malveillant imitant la page de connexion Microsoft. Cette application intercepte les identifiants de connexion et d’autres informations sensibles, facilitant ainsi l’accès non autorisé aux comptes Microsoft, tout en contournant les mesures de sécurité comme l’authentification multi-facteurs classiques.
Nicola Suter, MVP Microsoft, a lui aussi écrit un article inspiré par Zolder.io en démontrant qu’il est possible de créer un kit de phishing AiTM fonctionnant sur Azure. Les fonctions sur Azure peuvent imiter une page de connexion Entra ID, capter les identifiants et automatiser la reprise de session, tout en contournant des mécanismes de détection classiques.
AiTM, kesako ?
Une attaque AITM exploite un proxy intermédiaire pour intercepter les informations d’authentification pendant qu’un utilisateur se connecte à un service légitime, ce qui permet à l’attaquant de détourner la session et de contourner certaines sécurités mises en place par l’authentification multi-facteurs :
Il s’agit d’une nouvelle technique de phishing encore plus efficace. Cette méthode utilise des sites Web usurpés qui déploient un serveur proxy entre un utilisateur cible et le site Web que l’utilisateur souhaite visiter.
Contrairement au phishing classique, elles ne se contentent pas de tromper l’utilisateur pour lui soutirer ses identifiants. Voici en quoi elles consistent :
Interception en temps réel : L’attaquant crée une page de connexion factice qui sert d’intermédiaire (un proxy) entre la victime et le véritable site légitime. Ainsi, l’utilisateur se connecte en pensant accéder au service habituel, tandis que l’attaquant intercepte les identifiants, cookies et autres données sensibles en temps réel.
Bypass des mesures de sécurité : Puisque l’authentification se fait sur la vraie page (via le proxy), même si l’utilisateur passe une authentification multifacteur (MFA), les tokens et sessions générés peuvent être capturés par l’attaquant, qui peut ensuite les réutiliser pour prendre le contrôle du compte.
Utilisation d’outils serverless : Des plateformes comme Cloudflare Workers ou Azure Functions permettent de déployer rapidement ce type d’attaque sans gérer d’infrastructures traditionnelles, rendant ainsi l’attaque plus facile à mettre en œuvre et plus discrète.
L’attaquant peut voler et intercepter le mot de passe de la victime, détourner les sessions de connexion et le cookie de session (un cookie permet d’authentifier un utilisateur chaque fois qu’il visite un site) et ignorer le processus d’authentification, car le phishing AiTM n’est pas lié à une vulnérabilité dans l’authentification.
Oui, il est possible de réduire le risque contre les attaques AITM en mettant en œuvre une combinaison de mesures préventives et de détection. Voici quelques axes de défense :
Authentification renforcée :
MFA résistant au phishing : Adopter des méthodes d’authentification fortes et moins vulnérables au phishing (comme FIDO2, Windows Hello ou l’utilisation de certificats) permet de réduire les risques, car ces solutions reposent sur des mécanismes difficiles à intercepter via un proxy.
Politiques d’accès conditionnel : Restreindre l’accès aux services sensibles uniquement depuis des dispositifs conformes (registered devices) ou depuis des réseaux de confiance peut empêcher l’exploitation des sessions capturées.
Surveillance et détection :
Analyse comportementale : Mettre en place des outils de détection qui surveillent les anomalies dans les logs de connexion (par exemple, des connexions depuis des adresses IP inhabituelles ou issues des plages d’IP cloud reconnues) permet d’identifier rapidement une activité suspecte.
Canary tokens et autres mécanismes de vigilance : Bien qu’ils puissent parfois être contournés, ces outils permettent de détecter des modifications inattendues sur la page de connexion ou d’autres indices d’une attaque.
Sensibilisation des utilisateurs :
Former les utilisateurs à reconnaître les signes d’une tentative de phishing (URL étranges, absence de certificats de sécurité attendus, etc.) est une barrière importante contre ces attaques.
Encourager la vérification de l’authenticité des sites et des notifications de sécurité peut réduire le risque de compromission.
Gestion des sessions et réponses rapides :
En cas de compromission, disposer de procédures de réinitialisation rapides (révocation des sessions, changements de mots de passe, etc.) permet de limiter les dommages.
L’implémentation de solutions de sécurité capables d’alerter en temps réel sur des activités anormales (via par exemple Microsoft Entra ID Protection ou d’autres outils SIEM) renforce la réaction face à une attaque.
Dans cet article, je vous propose donc de tester 3 déploiements d’une application frauduleuse :
Maintenant, il nous reste plus qu’à tester tout cela 😎💪
Etape 0 – Rappel des prérequis :
Afin de mettre en place notre application frauduleuse de démonstration, nous allons avoir besoin de :
Une licence Microsoft Teams
Une souscription Azure valide pour le déploiement sur Azure (Etape IV)
Commençons par configurer Teams afin que nous puissions recevoir les notifications et les messages lorsque notre utilisateur de test s’est authentifié au travers de notre application frauduleuse.
Etape I – Configuration Teams :
Ouvrez votre console client de Teams afin de créer un nouveau canal dans l’équipe de votre choix :
Une fois le canal Teams créé, cliquez sur le bouton ci-dessous pour ajouter un connecteur externe :
Cliquez-ici pour ajouter le connecteur Webhook entrant en utilisant la barre de recherche :
Cliquez sur Ajouter :
Une fois le connecteur ajouté, cliquez sur Créer :
Copiez l’URI du connecteur Webhook dans un éditeur de texte :
Commençons par tester la méthode de déploiement proposée par zolder.io via Cloudflare.
Etape II – Méthode Cloudflare :
Cloudflare propose justement un plan gratuit qui permet d’utiliser les Cloudflare Workers, une plateforme serverless pour exécuter du code JavaScript.
Pour cela, connectez-vous sur la page suivante, puis créez un compte Cloudflare :
Si nécessaire, vérifiez votre compte Cloudflare grâce à l’e-mail reçu sur l’adresse renseignée :
Une fois sur votre tableau de bord Cloudflare, rendez-vous dans le menu suivant afin de créer un Worker :
Conservez ses propriétés de base, puis cliquez sur Déployer :
Une fois le Worker déployé, modifiez le code par le bouton ci-dessous :
Ouvrez un nouvel onglet vers ce répertoire GitHub, puis cliquez sur le fichier suivant :
Copiez le code du fichier worker.js :
Collez ce dernier dans un éditeur de texte :
Collez l’URI du connecteur Webhook Teams sur la ligne suivante :
Collez l’ensemble pour remplacer le code déjà présent sur votre worker Cloudflare, puis cliquez sur Déployer :
Attendez quelques secondes la mention de la sauvegarde en bas de page :
Cliquez sur ce lien afin d’ouvrir un nouvel onglet sur votre application frauduleuse :
Attendez quelques minutes et/ou rafraîchissez la page web plusieurs fois au besoin afin d’obtenir le résultat suivant :
Renseignez le nom de compte de votre utilisateur de test, puis cliquez sur Suivant :
Renseignez le mot de passe de votre utilisateur de test, puis cliquez sur Suivant :
Cliquez sur Oui :
Constatez la bascule sur la page web avec l’URL officielle de Microsoft, tout en n’étant toujours pas authentifié :
Retournez sur le canal Teams créé précédemment afin de constater l’apparition d’un premier message provenant du connecteur Webhook, et contenant le login et mot de passe de l’utilisateur de test :
Un second message Teams apparaît également dans le fil, ce dernier reprend les différents cookies générés sur le poste de la victime en relation avec le site officiel de Microsoft : login.onmicrosoft.com :
Copiez ce texte de cookies en entier :
Demandez à n’importe quelle IA générative de parser ce texte en JSON avec le prompt suivant :
Convertis cette chaîne de cookies en un snippet JavaScript qui utilise JSON.parse pour créer un tableau d’objets cookies, puis qui les applique avec document.cookie en leur assignant une date d’expiration fixe, comme dans cet exemple :
JSON.parse('[{"name":"ESTSAUTHPERSISTENT","value":"...","path":"/","domain":"login.microsoftonline.com","httpOnly":true},{"name":"ESTSAUTH","value":"...","path":"/","domain":"login.microsoftonline.com","httpOnly":true},{"name":"SignInStateCookie","value":"...","path":"/","domain":"login.microsoftonline.com","httpOnly":true}]').forEach(c => document.cookie = c.name + "=" + c.value + "; expires=Wed, 05 Aug 2040 23:00:00 UTC; path=/");
Copiez / collez le résultat obtenu par l’IA dans un éditeur de texte :
Une fois sur la page ci-dessous, appuyez sur la touche F12 de votre clavier afin d’ouvrir le mode Console de Google Chrome :
Collez le texte de cookies précédemment copié :
Chrome vous affiche une alerte et vous demande de réécrire la phrase suivante :
allow pasting
Collez à nouveau le texte de cookies, appuyez sur la touche Entrée, puis fermer la fenêtre Console :
Toujours sur la page ci-dessous, appuyez sur la touche F5 de votre clavier afin de rafraîchir la page web d’authentification Microsoft :
Une fois la page actualisée, constatez la bonne authentification de votre utilisateur de test grâce à l’exploitation des cookies interceptés par notre application frauduleuse :
Moins d’une heure après la publication de notre application frauduleuse chez Cloudflare, un nouvel e-mail nous informe de la détection de notre application et la fermeture de celle-ci :
La console Cloudflare de notre application frauduleuse devient alors inexploitable :
Enfin, il en est de même côté client pour l’URL générée pour notre application frauduleuse :
Continuons les tests en effectuant un déploiement en local de l’application frauduleuse.
Etape III – Méthode locale :
Rendez-vous sur la page suivante pour télécharger Node.js :
Lancez l’installation de Node.js, puis cliquez sur Suivant :
Cochez la case pour accepter les termes, puis cliquez sur Suivant :
Cliquez sur Suivant :
Cliquez sur Suivant :
Cliquez sur Suivant :
Cliquez sur Installer :
Une fois Node.js correctement installé, cliquez sur Terminer :
Rendez-vous sur la page suivante pour télécharger les outils d’exécution locale d’Azure Functions :
Lancez l’installation, puis cliquez sur Suivant :
Cochez la case pour accepter les termes, puis cliquez sur Suivant :
Cliquez sur Suivant :
Cliquez sur Installer :
Une fois les outils Azure Functions correctement installés, cliquez sur Terminer :
Rendez-vous sur la page suivante pour télécharger Visual Studio Code :
Cochez la case pour accepter les termes, puis cliquez sur Suivant :
Cliquez sur Suivant :
Cliquez sur Suivant :
Cliquez sur Suivant :
Cliquez sur Installer :
Une fois Visual Studio Code correctement installé, cliquez sur Terminer :
Ouvrez un nouvel onglet vers ce répertoire GitHub, puis cliquez-ici pour télécharger l’archive au format ZIP :
Décompressez l’archive ZIP dans un dossier local de votre choix :
Ouvrez Visual Studio Code, puis cliquez sur le bouton ci-dessous :
Choisissez le dossier précédemment créé en local :
Confirmez votre confiance en ce dernier :
Ouvrez par le menu suivant la console Terminal intégrée à Visual Studio Code :
Saisissez la commande suivante afin d’ajouter le webhook de votre canal Teams :
func settings add TEAMS_WEBHOOK_URI "https://"
Constatez l’apparition de votre configuration webhook Teams dans le fichier suivant :
Lancez la commande suivante pour installer le package @azure/functions dans votre projet Node.js et l’ajouter comme dépendance dans le fichier package.json.
npm install @azure/functions --save
Lancez la commande suivante pour démarrer l’application frauduleuse en local tout en affichant des informations détaillées de log pour le diagnostic.
func start --verbose
Choisissez node :
Attendez quelques secondes afin de constater le bon démarrages des 4 fonctions de l’application frauduleuse :
Copiez l’URL suivante :
Ouvrez, via Google Chrome en navigation privée, un onglet vers le site web de votre application frauduleuse hébergée sur Azure, renseignez le nom de compte d’un utilisateur de test ainsi que son mot de passe, puis cliquez sur s’authentifier :
Cliquez sur Oui :
Constatez la bascule sur la page web avec l’URL officielle de Microsoft, tout en n’étant toujours pas authentifié :
Retournez sur le canal Teams créé précédemment afin de constater l’apparition :
d’un premier message provenant du Webhook et contenant le login et mot de passe de l’utilisateur de test :
d’un second message Teams apparaît dans le fil, ce dernier reprend les différents cookies générés sur le poste de la victime en relation avec le site officiel de Microsoft : login.onmicrosoft.com :
Copiez ce texte de cookies en entier :
Ouvrez la page web suivante afin de convertir le format des cookies, collez votre texte de cookies précédemment copié, cliquez sur Convertir, puis copiez la valeur sortante parsée en JSON :
Ouvrez Google Chrome en navigation privée, puis rendez-vous sur la page officielle de Microsoft, puis cliquez-ici pour vous authentifiez :
Une fois sur la page ci-dessous, appuyez sur la touche F12 de votre clavier afin d’ouvrir le mode Console de Google Chrome :
Collez le texte de cookies précédemment copié :
Chrome vous affiche une alerte et vous demande de réécrire la phrase suivante :
allow pasting
Collez à nouveau le texte de cookies, appuyez sur la touche Entrée, puis fermer la fenêtre Console :
Toujours sur la page ci-dessous, appuyez sur la touche F5 de votre clavier afin de rafraîchir la page web d’authentification Microsoft :
Une fois la page actualisée, constatez la bonne authentification de votre utilisateur de test grâce à l’exploitation des cookies interceptés par notre application frauduleuse :
Terminons nos tests par un déploiement de notre application frauduleuse sur Azure.
Etape IV – Méthode Azure :
Ouvrez un onglet vers ce répertoire GitHub, puis cliquez-ici pour déployer votre application frauduleuse sur Azure :
Renseignez tous les champs ci-dessous dont également l’URI de votre webhook Teams, puis lancez la validation Azure:
Une fois la validation Azure réussie, lancez la création des ressources :
Attendez environ 10 minutes la fin de la création des ressources Azure, puis cliquez-ici :
Cliquez sur la fonction Azure créée lors du déploiement :
Copiez l’URL de votre application frauduleuse, puis vérifiez la bonne activation des différentes fonctionnalités :
Ajoutez au besoin un domaine personnalisé afin de rendre l’URL de votre site moins suspicieux :
Ouvrez, via Google Chrome en navigation privée, un onglet vers le site web de votre application frauduleuse hébergée sur Azure, renseignez le nom de compte d’un utilisateur de test ainsi que son mot de passe, puis cliquez sur s’authentifier :
Retournez sur le canal Teams précédemment créé afin de constater l’apparition :
d’un premier message provenant du Webhook et contenant le login et mot de passe de l’utilisateur de test :
d’un second message Teams apparaît dans le fil, ce dernier reprend les différents cookies générés sur le poste de la victime en relation avec le site officiel de Microsoft : login.onmicrosoft.com :
Copiez ce texte de cookies en entier :
Ouvrez la page web suivante afin de convertir le format des cookies, collez votre texte de cookies précédemment copié, cliquez sur Convertir, puis copiez la valeur sortante parsée en JSON :
Ouvrez Google Chrome en navigation privée, puis rendez-vous sur la page officielle de Microsoft, puis cliquez-ici pour vous authentifiez :
Une fois sur la page ci-dessous, appuyez sur la touche F12 de votre clavier afin d’ouvrir le mode Console de Google Chrome :
Collez le texte de cookies précédemment copié :
Chrome vous affiche une alerte et vous demande de réécrire la phrase suivante :
allow pasting
Collez à nouveau le texte de cookies, appuyez sur la touche Entrée, puis fermer la fenêtre Console :
Toujours sur la page ci-dessous, appuyez sur la touche F5 de votre clavier afin de rafraîchir la page web d’authentification Microsoft :
Une fois la page actualisée, constatez la bonne authentification de votre utilisateur de test grâce à l’exploitation des cookies interceptés par notre application frauduleuse :
Testons maintenant si l’ajout d’une MFA renforce la protection de notre compte de test.
Etape V – Ajout de Microsoft Authenticator :
Configurez une méthode MFA de type Microsoft Authenticator sur votre utilisateur de test :
Configurez une police d’accès conditionnel sur Entra ID afin d’exiger une méthode MFA à votre utilisateur de test :
Ouvrez, via Google Chrome en navigation privée, un onglet vers le site web de votre application frauduleuse hébergée sur Azure, renseignez le nom de compte d’un utilisateur de test ainsi que son mot de passe, puis cliquez sur s’authentifier :
Réussissez le challenge MFA demandé par Microsoft via la notification reçue sur votre compte Microsoft Authenticator :
Retournez sur le canal Teams précédemment créé afin de constater l’apparition :
d’un premier message provenant du Webhook et contenant le login et mot de passe de l’utilisateur de test :
d’un second message Teams apparaît dans le fil, ce dernier reprend les différents cookies générés sur le poste de la victime en relation avec le site officiel de Microsoft : login.onmicrosoft.com :
Copiez ce texte de cookies en entier :
Ouvrez la page web suivante afin de convertir le format des cookies, collez votre texte de cookies précédemment copié, cliquez sur Convertir, puis copiez la valeur sortante parsée en JSON :
Ouvrez Google Chrome en navigation privée, puis rendez-vous sur la page officielle de Microsoft, puis cliquez-ici pour vous authentifiez :
Une fois sur la page ci-dessous, appuyez sur la touche F12 de votre clavier afin d’ouvrir le mode Console de Google Chrome :
Collez le texte de cookies précédemment copié :
Chrome vous affiche une alerte et vous demande de réécrire la phrase suivante :
allow pasting
Collez à nouveau le texte de cookies précédemment copié, appuyez sur la touche Entrée, puis fermer la fenêtre du mode Console :
Toujours sur la page ci-dessous, appuyez sur la touche F5 de votre clavier afin de rafraîchir la page web d’authentification Microsoft :
Une fois la page actualisée, constatez la bonne authentification de votre utilisateur de test grâce à l’exploitation des cookies interceptés par notre application, sans souci particulier concernant l’instauration de la MFA :
Etape VI – Restriction des adresses IPs :
Configurez une police d’accès conditionnel avec une restriction sur votre adresse IP publique sur votre utilisateur de test afin d’empêcher toute autre lieu de s’y connecter :
L’utilisateur rencontrera alors sur l’application frauduleuse un message lui interdisant l’accès malgré sa bonne localisation :
Aucun cookie ne sera délivré, mais le mot de passe de l’utilisateur sera quand même récupéré :
Etape VII – Ajout d’une méthode MFA résistante au phishing :
Configurez une police d’accès conditionnel sur Entra ID afin d’exiger une méthode MFA résistante au phishing à votre utilisateur de test :
L’utilisateur rencontrera alors sur l’application frauduleuse un message lui interdisant l’accès :
Aucun cookie ne sera délivré, mais le mot de passe de l’utilisateur sera quand même récupéré :
Etape VIII – Restriction des postes locaux :
Configurez une police d’accès conditionnel sur Entra ID afin d’exiger une machine locale jointe à Entra ID pour votre utilisateur de test :
Malgré que la machine soit jointe à Entra ID et conforme, l’utilisateur rencontrera alors sur l’application frauduleuse un message lui interdisant l’accès :
Aucun cookie ne sera délivré, mais le mot de passe de l’utilisateur sera quand même récupéré :
Conclusion
Qu’il s’agisse d’un déploiement via Cloudflare, d’un environnement local ou d’un déploiement sur Azure, cela illustre la facilité avec laquelle ces attaques peuvent être exécutées.
Pourtant, elles soulignent également l’importance cruciale d’une authentification renforcée (avec des solutions telles que FIDO2 ou autres) et de politiques d’accès conditionnel strictes.
La surveillance continue, la gestion proactive des sessions et la sensibilisation des utilisateurs complètent ce dispositif de défense pour mieux protéger les environnements Cloud. Ces mesures, lorsqu’elles sont correctement implémentées, offrent une barrière robuste contre l’exploitation des failles de sécurité et renforcent significativement la protection des systèmes face aux menaces modernes.
Pour information, environ 12 heures après mon déploiement, la fonction Azure était toujours opérationnelle mais l’URL personnalisée avait bien été détectée et bloquée :
Le Web Sign-in de Windows 11 est une fonctionnalité innovante qui permet aux utilisateurs de se connecter à leur appareil Windows en utilisant autre chose que le mot de passe pour s’identifier. Introduite avec la version 22H2, cette méthode de connexion dite Passwordless utilise l’application Microsoft Authenticator. Elle est particulièrement utile dans les environnements nécessitant des connexions rapides et sécurisées, tout en éliminant le besoin de mémoriser un mot de passe complexe.
Cet article est la suite de l’article écrit précédemment et consacré à la mise en place du Passwordless sur les comptes Microsoft 365. Voici un lien direct de ce dernier.
Plusieurs méthodes d’authentification et pour quoi faire ?
Il est en effet possible d’avoir des méthodes utilisées en tant que méthode principale, tandis que d’autres ne seront acceptées que dans le cadre de la MFA, comme le rappelle très justement Microsoft :
Certaines méthodes d’authentification peuvent être utilisées en tant que facteur principal lorsque vous vous connectez à une application ou un appareil, par exemple à l’aide d’une clé de sécurité FIDO2 ou d’un mot de passe. D’autres méthodes d’authentification sont disponibles uniquement comme facteur secondaire lorsque vous utilisez une authentification multifacteur Microsoft Entra ou une SSPR.
Dois-je avoir une connexion internet active pour m’authentifier via Web Sign-in ?
La réponse est oui : Il faut disposer d’une connectivité internet active car l’authentification web Sign-in se fera obligatoirement par cette dernière.
A partir de quelle version Windows 11 Web Sign-in est compatible ?
Windows Pro
Windows Entreprise
Windows Pro Education/SE
Windows Éducation
Oui
Oui
Oui
Oui
À compter de Windows 11, version 22H2 avec KB5030310, vous pouvez activer une expérience de connexion web sur Microsoft Entra appareils joints. Cette fonctionnalité est appelée Connexion web et déverrouille de nouvelles options et fonctionnalités de connexion.
Dans cet article, je vous propose de mettre en place et de tester l’authentification Web Sign-in sur un poste Windows 11 via le Passwordless de l’application Microsoft Authenticator :
Pour réaliser cet exercice consacré au web Sign-in Windows, il vous faudra disposer de :
Un tenant Microsoft
Une souscription Azure valide
Un smartphone sous iOS ou Android ayant la dernière version de Microsoft Authenticator
Souhaitant faire un test sur une version propre d’un poste sous Windows 11, j’ai choisi de le simuler grâce à un environnement virtualisé Hyper-V recréé sous Azure. Il est en effet possible dans Azure d’imbriquer de la virtualisation. Cela demande malgré tout quelques exigences, comme le SKU de la machine virtuelle Hyper-V, mais aussi sa génération.
Mais avant cela, quelques configurations sont nécessaires au niveau du tenant.
Etape I – Configuration du tenant :
Pour cela, rendez-vous sur la page suivante d’Entra ID afin d’activer l’inscription automatique Windows, puis vérifiez le paramètre suivant :
Toujours sur le portail Entra ID, cliquez ici afin d’activer la méthode d’authentification principale via Microsoft Authenticator :
Si ce n’est pas encore le cas, activez la méthode d’authentification Microsoft Authenticator (article explicatif) :
Notre tenant dispose de la configuration nécessaire pour profiter du web Sign-in via le Passwordless. Nous allons pouvoir continuer la configuration de Windows 11 via une VM créée sous Azure.
Etape II – Préparation de la machine virtuelle Hyper-V :
Depuis le portail Azure, commencez par rechercher le service des machines virtuelles :
Cliquez-ici pour créer votre machine virtuelle Hyper-V :
Renseignez tous les champs, en prenant soin de bien sélectionner les valeurs suivantes :
Choisissez une taille de machine virtuelle présente dans la famille Dsv3 :
Cliquez sur Suivant :
Rajoutez un second disque pour stocker la VM Windows 11, puis cliquez sur Suivant :
Retirez l’adresse IP publique pour des questions de sécurité, puis lancez la validation Azure :
Une fois la validation réussie, lancez la création des ressources Azure :
Quelques minutes plus tard, cliquez-ici pour voir votre machine virtuelle Hyper-V :
Ensuite, cliquez-ici pour déployer le service Azure Bastion :
Peu après, constatez le déploiement réussi d’Azure Bastion, puis renseignez les identifiants renseignés lors de la création de votre VM Hyper-V :
Une fois connecté sur votre machine virtuelle Hyper-V, ouvrez Windows PowerShell :
Exécutez la commande suivante pour installer les deux rôles suivants :
Ouvrez le Gestionnaire de disques depuis le menu démarrer afin de configurer le disque de données ajouté sur votre VM Hyper-V :
Dès l’ouverture du Gestionnaire de disques, cliquez sur OK pour démarrer l’initialisation du disque de données :
Sur celui-ci, créez un nouveau volume :
Cliquez sur Suivant :
Cliquez sur Suivant :
Cliquez sur Suivant :
Cliquez sur Suivant :
Cliquez sur Terminer :
L’environnement Hyper-V est maintenant en place. Nous allons maintenant pouvoir créer ensemble une ou plusieurs machines virtuelles invitées.
Etape III – Préparation de la machine virtuelle Windows 11 :
Pour cela, il est nécessaire de récupérer l’image au format ISO afin de créer la machine virtuelle, puis d’y installer l’OS.
Pour ma part, je suis passé par mon abonnement Visual Studio :
Stockez le fichier ISO sur le disque F de votre VM Hyper-V :
Depuis votre VM Hyper-V, rouvrez votre console Hyper-V Manager, puis cliquez-ici pour créer votre machine virtuelle Windows 11 :
Cliquez sur Suivant :
Modifier les informations suivantes pour pointer vers le nouveau lecteur créé sur la VM Hyper-V, puis cliquez sur Suivant :
Pensez à bien choisir Génération 2 :
Comme indiqué, cette option ne sera plus modifiable par la suite.
Modifier la taille de la mémoire vive allouée à la VM Windows 11, puis cliquez sur Suivant :
Utilisez le switch créé précédemment, puis cliquez sur Suivant :
Cliquez sur Suivant :
Utilisez le fichier ISO de Windows 11 téléchargé précédemment, puis cliquez sur Suivant :
Cliquez sur Terminer pour finaliser la création de votre machine virtuelle Windows 11 :
Une fois la machine virtuelle créée, modifiez sa configuration comme ceci :
Dans la section Sécurité, cochez la case suivante pour activer la puce TPM :
Modifiez le nombre de processeurs virtuels afin d’accélérer l’installation de Windows 11, puis cliquez sur OK :
Double-cliquez sur votre machine virtuelle Windows 11 :
Cliquez-ici pour lancer le démarrage de la VM :
Appuyez sur n’importe quelle touche du clavier pour démarrer sur l’image ISO de Windows 11 :
Attendez que le chargement se termine :
La machine virtuelle est maintenant prête à installer Windows 11. Suivez toutes les étapes de l’installation.
Choisissez les informations de langue qui vous correspondent, puis cliquez sur Suivant :
Lancez l’installation de Windows 11 :
Attendez que le démarrage de l’installation se lance, puis choisissez une version de Windows 11, puis cliquez sur Suivant :
Acceptez les termes et conditions de Microsoft, puis cliquez sur Suivant :
Sélectionnez l’installation personnalisée de Windows 11 :
Validez l’installation sur le seul disque disponible, puis cliquez sur Suivant :
Attendez maintenant que l’installation de Windows 11 commence :
Lancez le redémarrage de la machine virtuelle Windows 11 :
Attendez quelques minutes que le redémarrage se poursuivre :
Sélectionnez le pays adapté, puis cliquez sur Oui :
Choisissez le clavier correspondant au vôtre, puis cliquez sur Oui :
Ajoutez, si besoin, un second clavier :
Attendez que l’installation de Windows 11 vérifie si de nouvelles mises à jour OS sont disponibles :
Nommez votre machine virtuelle Windows 11 selon vos souhaits, puis cliquez sur Suivant :
Attendez quelques minutes la fin de la configuration :
Adaptez la configuration des paramètres de confidentialité, puis cliquez sur Accepter :
Attendez quelques minutes la seconde vérification des mises à jour OS :
Attendez enfin la finalisation de la configuration de Windows 11 :
Finaliser la sécurisation de votre poste en configurant Windows Hello en cliquant sur OK :
Définissez le code PIN de votre choix, puis cliquez sur OK :
Cliquez à nouveau sur OK :
Vous voilà enfin sur le bureau Windows de votre machine virtuelle Windows 11 :
L’environnement Windows 11 pour notre test est maintenant opérationnel. Afin de déployer la configuration Web Sign-in, nous allons la pousser via la console de gestion Intune.
Etape IV – Configuration Intune – Web Sign-in :
Rendez-vous à nouveau sur le portail Entra ID afin de vérifier que la machine virtuelle Windows 11 jointe grâce à notre utilisateur de test y figure bien :
Rendez-vous également sur le portail Intune afin de vérifier que la machine virtuelle Windows 11 y figure également :
Cliquez-ici pour créer une nouvelle police de configuration Windows :
Choisissez la configuration de profil suivante, puis cliquer sur Créer :
Nommez votre profil de configuration, puis cliquez sur Suivant :
Cliquez ici pour ajouter un ou des paramètres à votre profil :
Recherchez par mot clef, cliquez sur la catégorie suivante, puis choisissez le paramètre suivant :
Activez le paramètre repris, puis cliquez sur Suivant :
Cliquez sur Suivant :
Sélectionnez un groupe de machines en rapport avec le test, puis cliquez sur Suivant :
Vérifiez la configuration de votre profil, puis lancez sa création :
La nouvelle police de configuration apparaît alors dans la liste :
Continuer la configuration Intune via la création d’une seconde police de configuration si vous souhaitez désactiver l’ouverture de session Windows via le mot de passe.
Etape V – Configuration Intune – Passwordless :
Cliquez-ici pour créer une seconde police de configuration Windows :
Choisissez la même configuration de profil, puis cliquer sur Créer :
Nommez votre second profil de configuration, puis cliquez sur Suivant :
Recherchez par mot clef, cliquez sur la catégorie suivante, puis choisissez le paramètre suivant :
Activez le paramètre ci-dessous, puis cliquez sur Suivant :
Cliquez sur Suivant :
Sélectionnez un groupe de machines en rapport avec le test, puis cliquez sur Suivant :
Vérifiez la configuration de votre second profil, puis lancez sa création :
La seconde police de configuration apparaît alors dans la liste :
Cliquez ici pour voir le détail de son déploiement sur votre poste de test, attendez plusieurs minutes, puis rafraîchissez cette page plusieurs fois au besoin :
Afin d’accélérer le processus, vous pouvez déclencher une synchronisation Intune via le menu suivant sous Windows 11 :
Cliquez sur le bouton suivant, puis attendez environ 5 minutes :
Une fois la configuration correctement déployée, il ne nous reste qu’à tester l’ouverture de session Windows de notre utilisateur.
Alternative :
En alternative à Intune, il aurait été possible travailler sur le registre Windows pour agir directement sur la configuration Passwordless et Web Sign-in :
Pour cela, fermez la session Windows 11 actuellement ouverte :
De retour sur la mire d’authentification, cliquez sur le bouton suivant afin de constater la différentes méthodes d’authentification autorisées :
Cliquez selon votre cas sur le bouton Sign in ou Web Sign in :
Constatez l’apparition d’une fenêtre d’authentification Entra ID vous proposant d’envoyer une notification sur votre Smartphone configuré comme Passwordless :
Sur votre smartphone, saisissez le nombre précédemment affiché :
Juste après, constatez la bonne ouverture de la session Windows 11 :
Enfin, ouvrez les propriétés Windows de votre compte de test afin d’y constater l’absence de méthode consacrée au mot de passe :
Conclusion
La fonctionnalité Web Sign-in de Windows 11 marque une avancée notable dans la sécurisation et la simplification des méthodes de connexion.
En éliminant l’usage des mots de passe traditionnels, elle permet aux utilisateurs de s’authentifier via un navigateur web en utilisant l’application Microsoft Authenticator.
Disponible à partir de la version 22H2 de Windows 11, cette solution s’inscrit dans la continuité de la stratégie Passwordless Cloud de Microsoft.
Enfin, Windows 11 web Sign-in est également compatible avec Temporary Access Pass 😎
Très souvent, la sécurité d’un périmètre ou d’un environnement focalise une attention particulière aux processus d’authentification ainsi qu’aux moyens mis à disposition aux utilisateurs pour y parvenir. Quelles méthodes, quelles conditions, quels protocoles mettre en place ? La MFA est un principe de base maintenant acquis pour tous et set présent dans une majorité de systèmes, mais le mot de passe reste alors encore de la partie.
Qu’est-ce que le Passwordless ?
Le concept de Passwordless (sans mot de passe) désigne une méthode d’authentification qui permet aux utilisateurs de se connecter à des systèmes ou des services sans avoir à utiliser un mot de passe traditionnel.
Autrement dit, le concept de Passwordless regroupe plusieurs méthodes d’authentification différentes, comme :
Passkey via Microsoft Authenticator
Push via Microsoft Authenticator
FIDO2
Windows Hello
SmartCard
Pourquoi vouloir se débarrasser du mot de passe ?
L’objectif principal du Passwordless est de réduire les risques de compromission liés aux mots de passe traditionnels, comme les attaques par hameçonnage (phishing), les vols de mot de passe, ou encore les mauvaises pratiques liées à la gestion des mots de passe (mots de passe faibles ou réutilisés).
Passwordless vs MFA ?
Passwordless et MFA (Multi-Factor Authentication) sont 2 méthodes d’authentification sécurisée, mais elles diffèrent dans leur approche et leur mise en œuvre.
Des fonctionnalités telles que l’authentification multifacteur (MFA) sont un excellent moyen de sécuriser votre organisation, mais les utilisateurs sont souvent frustrés par la couche de sécurité supplémentaire en plus de devoir mémoriser leurs mots de passe.
Les méthodes d’authentification sans mot de passe sont plus pratiques, car le mot de passe est supprimé et remplacé par quelque chose que vous avez ou quelque chose que vous êtes ou connaissez.
Combinaison de mot de passe + SMS, email, biométrie
Exemples d’utilisation
Connexion par empreinte digitale, lien magique
Connexion par mot de passe + code SMS ou app Authenticator
Dans cet article, je vous propose de mettre en place et de tester l’authentification Passwordless via l’application Microsoft Authenticator sur smartphone pour une identité 365 :
Pour réaliser cet exercice sur la méthode Passwordless de Microsoft, il vous faudra disposer de :
Un tenant Microsoft
Un smartphone sous iOS ou Android ayant la dernière version de Microsoft Authenticator
Important : à l’issue de cette démonstration, gardez en tête que votre smartphone sera enregistré (mais non managé) dans chaque tenant Microsoft où il sera utilisé pour se connecter en Passwordless.
Commençons par activer le service Passwordless sur le tenant 365.
Etape I – Configuration du tenant :
Pour cela, rendez-vous dans la section suivante de votre portail Entra, puis cliquez sur Microsoft Authenticator :
Si ce n’est pas encore le cas, activez la méthode d’authentification Microsoft Authenticator :
Définissez le périmètre des utilisateurs concernés en laissant le mode d’authentification à Any ou Passwordless :
Basculez sur le second onglet afin d’activer ou non Microsoft Authenticator OTP :
Afin de comprendre le fonctionnement du processus depuis l’enrôlement de départ de Microsoft Authenticator, il est préférable de créer un utilisateur de test.
Etape II – Configuration du l’utilisateur :
Toujours sur votre portail Entra, cliquez ici pour créer un nouvel utilisateur sur votre tenant Microsoft :
Renseignez-lui un UPN, un nom d’affichage, ainsi qu’un mot de passe temporaire, puis lancez la validation Entra :
Une fois la validation Entra réussie, lancez la création de votre utilisateur des test :
Une fois l’utilisateur créé, ouvrez le navigateur internet de votre choix en mode privé :
Rendez-vous sur la page office.com, puis cliquez ici pour vous authentifier :
Saisissez le nom de compte de votre utilisateur de test ainsi que son mot de passe provisoire :
Définissez un nouveau mot de passe :
Cliquez sur Oui :
Notre environnement 365 et notre utilisateur sont maintenant créé.
Passons maintenant à l’étape suivante qui consiste à associer Microsoft Authenticator à notre compte de test.
Etape III – Configuration MFA :
En haut à droite, cliquez ici pour afficher les propriétés de votre compte 365 :
Dans l’onglet dédié aux informations de sécurité, ajoutez une nouvelle méthode d’authentification :
Choisissez la méthode suivante pour configurer Microsoft Authenticator :
Installez au besoin l’application Microsoft Authenticator depuis un store d’applications, puis cliquez sur Suivant :
Cliquez sur Suivant :
Choisissez le type Compte professionnel ou scolaire :
Cliquez ici pour utiliser l’appareil photo afin de scanner le QR code :
Scanner le QR code présenté par Microsoft :
Une fois scanné, cliquez sur Suivant :
Une notification est alors envoyée à votre smartphone :
Saisissez le nombre précédemment affiché, puis cliquez sur Oui :
Confirmez votre identité sur le smartphone via un code PIN ou une empreinte digitale :
La méthode Microsoft Authenticator est maintenant correctement configurée sur votre compte de test, cliquez alors sur Suivant :
La méthode Microsoft Authenticator apparaît alors sur votre compte en tant que méthode dite MFA :
L’utilisateur de test est maintenant correctement configuré avec un mot de passe traditionnel et une méthode de sécurité de type MFA.
Etape IV – Configuration Passwordless :
Afin d’activer la méthode Passwordless, nous allons transformer le compte de test enregistré sur l’application Microsoft Authenticator.
Pour cela, ouvrez l’application Microsoft Authenticator, sélectionnez votre compte de test, puis cliquez ici pour activer la fonctionnalité Passwordless :
Microsoft vous informe que l’appareil sera inscrit dans le tenant ID correspondant, cliquez sur Continuer
Sur l’application Microsoft Authenticator, renseignez le mot de passe de votre compte de test :
Un nombre apparaît alors sur la fenêtre, ainsi qu’une notification Microsoft Authenticator, vous demandant de ressaisir ce dernier :
Confirmez votre identité sur le smartphone via un code PIN ou une empreinte digitale :
Cliquez ici pour confirmer l’enregistrement de votre smartphone sur le tenant ID concerné :
Microsoft Authenticator vous confirme le succès des opérations et de l’activation de la fonctionnalité Passwordless, cliquez alors sur Terminer :
Retournez sur le portail Entra afin de constater l’apparition de votre smartphone en tant que périphérique enregistré :
De retour sur les éléments de sécurité de votre utilisateur de test, la méthode Microsoft Authenticator s’est transformée de MFA à Passwordless :
Tout notre environnement de test est maintenant configuré. Il ne nous reste qu’à tester que la méthode Passwordless fonctionne correctement à la place du mot de passe.
Etape V – Test du Passwordless :
Rouvrez à nouveau un navigateur internet en mode privée :
Rendez-vous à nouveau sur la page office.com, puis cliquez ici pour vous authentifier :
Saisissez le nom de compte de votre utilisateur de test, puis, au lieu de renseigner son mot de passe, cliquez sur le choix suivant :
Microsoft envoie alors une notification sur le smartphone configuré comme Passwordless :
Ouvrez la notification Microsoft Authenticator, puis ressaisissez le nombre précédemment indiqué par Microsoft :
De retour sur votre navigateur, confirmez votre souhait de rester authentifié en cliquant sur Oui :
La page d’accueil d’Office 365 s’ouvre bien, l’utilisateur s’est correctement authentifié sans mot de passe :
Côté traçabilité, il est possible de retrouver des logs des authentifications Passwordless dans plusieurs écrans de Microsoft :
Côté Administrateur, via la vue des logs d’un utilisateur sur Entra ID :
Ou via une requête KQL après l’activation Log Analytics sur Entra ID :
SigninLogs
| where AuthenticationDetails has "passwordless"
| project TimeGenerated, UserPrincipalName, AuthenticationDetails , ResultDescription
| order by TimeGenerated desc
Conclusion
En conclusion, l’adoption du Passwordless avec Microsoft Authenticator constitue une avancée significative dans la sécurisation des environnements numériques tout en améliorant l’expérience utilisateur.
En éliminant la nécessité de mémoriser et de gérer des mots de passe, cette méthode réduit les risques liés aux compromissions, telles que les attaques de phishing ou le vol de mots de passe.
De plus, elle simplifie les processus d’authentification, rendant l’accès aux services plus fluide. Pour les entreprises, c’est une opportunité d’offrir un meilleur équilibre entre sécurité et facilité d’utilisation, tout en renforçant la confiance des utilisateurs dans la protection de leurs données.
La vérification faciale est une solution qui existe chez plusieurs éditeurs et qui compare des visages tout en respectant la vie privée. Elle aide les entreprises à vérifier l’identité des personnes de manière sécurisée et efficace. Par exemple, une banque peut l’utiliser pour s’assurer que la personne ouvrant un compte est bien celle qu’elle prétend déclarer. Mais peut-on combiner cette fonctionnalisé avec Entra Verified ID ?
La réponse est oui :
La correspondance faciale est alimentée par Azure AI services. En partageant uniquement les résultats de correspondance et non les données d’identité sensibles, Vérification faciale protège la confidentialité des utilisateurs tout en permettant aux organisations de s’assurer que la personne est bien qui elle prétend être.
Combinée à Entra Verified ID, Face check permettra alors une expérience plus rapide dans le partage d’une identité :
La documentation Microsoft explique d’ailleurs très bien le concept et l’intégration dans une application, mais également une FAQ disponible juste ici.
Vérification faciale vs Face ID ?
Face ID est une offre d’option de sécurité biométrique basée sur la vision pour les produits Apple pour déverrouiller un appareil en vue d’accéder à une application mobile. Vérification faciale est une fonctionnalité de Vérification d’identité Microsoft Entra qui utilise également la technologie IA basée sur la vision, mais compare l’utilisateur au justificatif Vérification d’identité présenté… Les deux mécanismes requièrent que l’utilisateur soit face à une caméra dans le processus, mais fonctionne de différentes manières.
Les données ne sont ni stockées ni conservées par aucun des services Microsoft Authenticator, Vérification d’identité ou Azure AI. En outre, les images ne sont pas non plus partagées avec l’application de vérificateur. L’application de vérificateur obtient uniquement le score de confiance en retour.
Dans un système basé sur l’IA, le score de confiance est la réponse de pourcentage de probabilité pour une requête au système. Pour ce scénario, le score de confiance est la probabilité que la photo du justificatif de l’utilisateur Vérification d’identité corresponde à la capture de l’utilisateur sur l’appareil mobile.
Pour cette démonstration de Face Check, choisissez la configuration rapide :
Si votre tenant contient plusieurs domaines personnalisés, choisissez celui que vous souhaitez mettre en place pour ce service d’identité vérifiée, puis cliquez sur Sauvegarder :
La configuration sur votre tenant se met alors en place, Entra vous invite à patienter environ 1 minute :
Une fois la configuration automatique terminée, la notification suivante apparaît :
Afin de configurer Face Check, nous avons besoin de créer un groupe de ressources Azure. Rendez-vous sur le portail Azure, puis cliquez ici :
Cliquez ici pour créer un nouveau groupe de ressources Azure :
Renseignez les informations de base pour ce groupe de ressources, puis lancez la validation Azure :
Une fois la validation Azure réussie, lancez la création du groupe de ressources :
Retournez sur le portail d’Entra ID afin d’activer l’addon Face Check :
Prenez le temps de lire les conditions tarifaires de Face Check, dont le prix sera appliqué à partir du 12 août 2024 :
Renseignez vos informations Azure concernant le groupe de ressources créé précédemment, puis cliquez sur Valider :
Une fois la validation Azure réussie, cliquez sur Activer :
La notification Entra suivante apparaît alors :
La configuration du service Verified ID destiné à Face Check est maintenant terminée. Nous allons avoir maintenant besoin de créer un utilisateur de test.
Etape II – Création d’un utilisateur de test :
Toujours sur le portail Entra, créez un nouvel utilisateur Entra ID :
Renseignez les informations de base de cet utilisateur, puis cliquez sur Suivant :
Renseignez également une adresse de messagerie :
Renseignez également un pays de localisation, puis lancez la validation Entra :
Lancez la création de votre utilisateur de test :
La notification Entra suivante apparaît alors :
Une fois l’utilisateur de test créé, ajoutez une photo de vous sur le profil de ce dernier :
Ouvrez le navigateur de votre choix en mode privé :
Ouvrez la page Mon compte de Microsoft, puis authentifiez-vous avec votre utilisateur de test :
A votre première connexion, personnalisez son mot de passe :
Cliquez ici afin d’obtenir une identité vérifiée :
Microsoft génère alors un QR code pour générer et stocker une identité vérifiée dans l’application Microsoft Authenticator de votre smartphone :
Sur votre smartphone, ouvrez Microsoft Authenticator, puis cliquez ici pour scanner le QR Code :
Confirmez l’ajout de votre identité vérifiée en cliquant sur Ajouter :
Sur votre smartphone, un clic sur votre identité vérifiée affiche les informations stockées dans cette dernière, dont votre photo :
Une première activité correspondante à la réception de cette identité vérifiée est visible juste ici :
Cette nouvelle identité vérifiée rejoint les autres déjà en place dans Microsoft Authenticator :
La prochaine étape sera de créer une application de test pour vérifier le bon fonctionnement de Face Check pour notre nouvel utilisateur.
Sur la portail Entra, copiez votre DID afin de la configurer plus tard dans l’application :
Rendez-vous sur la page GitHub suivante, puis déployez l’application sur votre tenant par ce lien :
Renseignez les 2 champs suivants, puis lancez la validation Azure :
Une fois la validation Azure réussie, lancez la création des ressources :
Attendez environ 5 minutes la fin du déploiement Azure, qui devrait peut-être présenter l’erreur non bloquante suivante, puis cliquez ici pour continuer :
Vérifiez que l’application déployée dispose bien de sa propre identité :
Copiez le script ci-dessous dans un éditeur de texte en prenant soin de renseigner les deux informations suivantes propres à votre déploiement :
Toujours sur le portail Azure, ouvrez par ce bouton Azure Cloud Shell :
Exécutez le script précédemment modifié, puis attendez le résultat suivant :
Retournez sur le portail Entra, puis recherchez votre application de test :
Vérifiez la présence de la permission suivante nécessaire à la gestion des identités vérifiées :
Tout est maintenant en place, il nous reste qu’à tester notre application.
Etape IV – Test application via Face Check :
Retournez sur le portail Azure afin de copier l’URL web de votre application de test :
Ouvrez un nouvel onglet vers cette URL de test, puis cliquez ici :
Votre application génère alors un QR code à scanner :
Depuis votre smartphone, ouvrez Microsoft Authenticator afin de scanner le QR code :
Confirmez votre action de partage de votre identité vérifiée avec votre application de test en cliquant sur Suivant :
Cliquez sur Suivant pour démarrer la vérification avec votre visage :
Suivez les indications de l’application afin de valider l’opération Face Check :
Le message suivant vous confirme le succès de la vérification Face Check :
Cliquez à nouveau sur Partager pour confirmer l’action :
Votre application web vous confirme bien le succès du partage et le score retourné par la fonction Face Check :
Une nouvelle activité Woordgrove Helpdesk s’ajoute sur votre identité vérifiée :
Quelques informations supplémentaires sur ce partage sont disponibles :
Conclusion
L’identité décentralisée promet de redonner le contrôle des données aux utilisateurs, en assurant une gestion sécurisée et privée des identités numériques :
Contrôle et Sécurité : Les utilisateurs gèrent leurs propres identifiants et données, réduisant les risques de violations et d’usurpation d’identité.
Confidentialité : Les données personnelles sont partagées uniquement avec consentement explicite, sans intermédiaires centralisés.
Interopérabilité : Utilisation de normes ouvertes (comme les DID et justificatifs vérifiables), permettant une intégration fluide avec divers systèmes.
Fiabilité : Justificatifs émis par des entités de confiance, validés de manière sécurisée et infalsifiable.
Pour continuer sur le sujet des identités vérifiées disponibles sur Microsoft Entra (dont un premier article est disponible juste ici), je vous propose dans ce second de suivre un tutoriel élaboré par Microsoft qui est assez intéressant : Il s’agit de créer votre propre système d’identité vérifié personnalisé.
Apprenez à émettre et à vérifier des informations d’identification à l’aide du même locataire Microsoft Entra… Dans ce tutoriel, vous passez en revue les étapes nécessaires à la présentation et à la vérification de votre premier justificatif vérifiable : une carte d’expert en justificatif vérifié.
Microsoft nous montre au travers de ce schéma le fonctionnement d’une application tierce et des interactions avec le service Entra Verified ID de notre tenant :
Comme toujours, je vous propose de suivre ensemble ce pas à pas dans le but de tester ce tutoriel :
Pour cette démonstration, choisissez la Configuration rapide :
Si votre tenant contient plusieurs domaines personnalisés, choisissez celui que vous souhaitez mettre en place pour votre service d’identité vérifiée, puis cliquez sur Sauvegarder :
La configuration sur votre tenant se met alors en place, Microsoft Entra vous invite à patienter environ 1 minute :
Une fois la configuration automatique terminée, la notification suivante apparaît :
Téléchargez puis installez la version 6.0 de .NET, disponible via ce lien officiel :
Afin de publier votre application sur une URL internet, téléchargez ngrok, puis inscrivez-vous chez eux avec un compte gratuit :
Sur leur site, téléchargez l’installateur de ngrok :
Copiez la commande suivante affichée sous l’installateur pour configurer votre ngrok :
Depuis le dossier de téléchargement, ouvrez une invite de commande, puis lancez celle-ci afin de préparer votre configuration ngrok :
Le poste local et le tenant Microsoft sont maintenant correctement configurés, la prochaine étape consiste à créer une justificatif vérifiable personnalisé (pouvant générer des identités vérifiées) sur votre tenant.
Etape III – Création d’un justificatif vérifiable personnalisé :
Depuis le portail Microsoft Entra, cliquez ici pour ajouter un Justificatif vérifiable personnalisé :
Sélectionnez Informations d’identification personnalisée, puis cliquez sur Suivant :
Nommez votre Justificatif vérifiable comme ceci :
Dans la première section destinée aux propriétés d’affichage, remplacez le code existant par celui-ci :
{
"locale": "en-US",
"card": {
"title": "Verified Credential Expert",
"issuedBy": "Microsoft",
"backgroundColor": "#000000",
"textColor": "#ffffff",
"logo": {
"uri": "https://didcustomerplayground.blob.core.windows.net/public/VerifiedCredentialExpert_icon.png",
"description": "Verified Credential Expert Logo"
},
"description": "Use your verified credential to prove to anyone that you know all about verifiable credentials."
},
"consent": {
"title": "Do you want to get your Verified Credential?",
"instructions": "Sign in with your account to get your card."
},
"claims": [
{
"claim": "vc.credentialSubject.firstName",
"label": "First name",
"type": "String"
},
{
"claim": "vc.credentialSubject.lastName",
"label": "Last name",
"type": "String"
}
]
}
Dans la seconde section destinée à la Définition de règles, remplacez le code existant par celui-ci, puis cliquez sur Créer :
Une fois la configuration terminée, une notification Microsoft Entra apparaît :
Le Justificatif vérifiable est maintenant créé. Ses informations de base sont disponibles sur cette page :
Copiez l’URL du manifeste afin de la configurer plus tard dans votre application :
Copiez votre DID afin de la configurer plus tard dans votre application :
Copiez votre tenant ID afin de la configurer plus tard dans votre application :
L’environnement côté Microsoft Entra est maintenant en place. Pour que notre application fonctionne, il est nécessaire renseigner les informations de connexion précédemment copiées.
Etape IV – Création de l’application :
Téléchargez l’archive ZIP de l’application de test disponible sur ce lien GitHub :
Une fois l’archive ZIP téléchargée, débloquez cette dernière par un clic droit sur celle-ci, puis cliquez sur OK :
Lancez l’extraction de l’archive dans le répertoire de votre choix :
Retournez sur le portail de Microsoft Entra ID afin de créer une nouvelle inscription d’application :
Nommez votre application comme ceci, configurez la pour fonctionner uniquement sur votre tenant, puis cliquez sur Enregistrer :
Cliquez sur le menu suivant afin d’ajouter des permissions à votre application :
Ajoutez la permission API suivante utilisée par votre organisation :
Sélectionnez cette permission API, puis cliquez sur Ajouter :
Ajoutez un consentement global de l’administrateur pour votre tenant :
Confirmez votre action en cliquant sur Oui :
Copiez l’ID de votre d’application afin de la configurer plus tard dans votre application :
Cliquez sur le menu suivant afin de créer un secret pour votre application :
Nommez votre secret, puis cliquez sur Ajouter :
Une fois créé, copiez la valeur de votre secret afin de la configurer plus tard dans votre application :
Ouvrez votre éditeur de code local :
Ouvrez le dossier correspondant au dossier contenant l’extraction de l’archive ZIP :
Confirmez votre confiance dans ce répertoire :
Dans le dossier 1.asp-net-core-api-idtokenhint, ouvrez le fichier appsettings.json, puis mettez à jour les propriétés suivantes avec les informations que vous avez copiées lors des étapes précédentes :
Manifeste des informations d’identification : l’URL de votre manifeste
ID de locataire : votre ID de votre tenant
ID client : votre ID de votre inscription d’application
Secret client : votre secret client de votre inscription d’application
DidAuthority : votre identificateur décentralisé
Retirez les 2 commentaires présents dans ce même fichier :
Sauvegardez le fichier appsettings.json:
Ouvrez une première fenêtre Windows Terminal, positionnez-vous dans le dossier contenant l’extraction de l’archive ZIP, puis saisissez la commande suivante :
Une fois la compilation terminée, démarrez votre application via la commande suivante :
dotnet run
Une fois l’application démarrée, ouvrez une seconde fenêtre Windows Terminal, puis saisissez la commande suivante afin d’exposer votre application locale au travers de ngrok :
.\ngrok http 5000
Une fois votre application exposée, copiez l’URL générée par ngrok :
Tout l’environnement de test est maintenant en place, il nous reste qu’à tester le fonctionnement du service personnalisé d’identité vérifiée.
Etape V – Test d’émission d’une identité vérifiée :
Ouvrez un navigateur privé, collez l’URL ngrok précédemment copiée, puis confirmez la navigation en cliquant ici :
Votre application doit ressembler à ceci :
Cliquez ici afin d’obtenir une identité vérifiée :
Confirmez votre action en cliquant ici :
L’application génère alors un QR code pour stocker une identité vérifiée dans l’application Microsoft Authenticator de votre smartphone :
Sur votre smartphone, ouvrez Microsoft Authenticator, puis cliquez ici pour scanner le QR Code :
Saisissez le code de vérification visible sous le QR code de votre application, puis cliquez sur Suivant :
Confirmez l’ajout de votre identité vérifiée en cliquant sur Ajouter :
L’application confirme bien le stockage sur l’application Microsoft Authenticator de votre smartphone :
Sur votre smartphone, un clic sur votre identité vérifiée affiche les informations stockées dans cette dernière :
Une première activité correspondante à la réception de cette identité vérifiée est visible juste ici :
Cette nouvelle identité vérifiée rejoint les autres déjà en place dans Microsoft Authenticator :
La prochaine étape consiste à vérifier sa validité au travers de la seconde fonctionnalité de votre application.
Etape VI – Test de la vérification d’une identité vérifiée :
Retournez sur page principale de votre application, puis cliquez ici :
Cliquez ici pour confirmer votre action :
La vérification d’une identité vérifiée passe par le scan d’un QR code :
Ouvrez Microsoft Authenticator sur votre smartphone, puis utilisez la fonction suivante pour scanner le QR code généré par votre application :
Votre application vous indique que la vérification de l’identité vérifiée a bien fonctionné :
Conclusion
L’identité décentralisée promet de redonner le contrôle des données aux utilisateurs, en assurant une gestion sécurisée et privée des identités numériques :
Contrôle et Sécurité : Les utilisateurs gèrent leurs propres identifiants et données, réduisant les risques de violations et d’usurpation d’identité.
Confidentialité : Les données personnelles sont partagées uniquement avec consentement explicite, sans intermédiaires centralisés.
Interopérabilité : Utilisation de normes ouvertes (comme les DID et justificatifs vérifiables), permettant une intégration fluide avec divers systèmes.
Fiabilité : Justificatifs émis par des entités de confiance, validés de manière sécurisée et infalsifiable.
Dans un monde où nos vies numériques et physiques sont inextricablement liées, la sécurité des identités est primordiale. Les violations de données et l’usurpation d’identité sont des menaces croissantes.
Pour contrer cela, Microsoft s’intègre dans l’idée d’une solution innovante d’identité décentralisée qui donne aux utilisateurs le contrôle de leurs informations, éliminant la dépendance aux autorités centralisées et aux intermédiaires. Voici d’ailleurs ici quelques notions présentées par Microsoft.
Et voilà les différents points abordés dans cet article :
Notre identité numérique est utilisée partout, souvent sans notre consentement éclairé. Actuellement, nos données sont contrôlées par des tiers, ce qui présente des risques de sécurité. Une identité décentralisée permet aux utilisateurs de contrôler et sécuriser leurs informations personnelles :
Microsoft travaille-t-il seul dans son coin ?
La réponse est bien évidemment non 🙏
Microsoft collabore activement avec les membres de la DIF (Decentralized Identity Foundation), du W3C Credentials Community Group et de la communauté plus étendue en lien avec l’identité. Nous avons travaillé avec ces groupes pour identifier et développer des normes critiques, et les normes suivantes ont été implémentées dans nos services.
Qu’est-ce que sont les identificateurs décentralisés (DID) ?
Les DID sont des identifiants uniques créés et contrôlés par les utilisateurs, résistants à la censure et immuables. Ils permettent de prouver des informations sans dépendre de systèmes centralisés :
Qu’est-ce qu’un justificatif vérifiable ?
Les justificatifs vérifiables sont des attestations numériques signées par des entités de confiance. Ils fonctionnent comme des preuves de diplômes, permis ou autres certifications, mais sous une forme numérique sécurisée.
L’application France Identité en est d’ailleurs un bonne exemple puis qu’elle permet le stockage des nouvelles cartes d’identité française ou le permis de conduire :
Comment fonctionne l’identité décentralisée ?
Nous avons besoin d’une nouvelle forme d’identité. Nous avons besoin d’une identité capable de réunir des technologies et des normes pour fournir des attributs d’identité clés tels que l’indépendance et la résistance à la censure. Ces fonctionnalités sont difficiles à obtenir à l’aide des systèmes existants.
Pour y parvenir, il nous faut nous appuyer sur une base technique composée de sept innovations clés. Les identificateurs détenus par l’utilisateur constituent l’une de ces innovations clés, un agent utilisateur pour gérer les clés associées à ces identificateurs et les magasins de données chiffrés et contrôlés par l’utilisateur.
1. Identificateurs décentralisés (DID) W3C. ID créés, détenus et contrôlés par les utilisateurs indépendamment de toute organisation ou de tout gouvernement. Les DID sont des identificateurs globaux uniques liés à des métadonnées DPKI (Decentralized Public Key Infrastructure) composés de documents JSON contenant des éléments de clé publique, des descripteurs d’authentification et des points de terminaison de service.
2. Système d’approbation. Pour pouvoir résoudre les documents DID, les DID sont généralement enregistrés sur un réseau sous-jacent d’un type qui représente un système d’approbation. Microsoft prend actuellement en charge le système d’approbation DID :Web. DID:Web est un modèle basé sur des autorisations qui autorise l’approbation à l’aide de la réputation existante d’un domaine web. DID:Web est dans l’état de pris en charge Disponibilité générale.
3. Agent utilisateur/Portefeuille DID : application Microsoft Authenticator. Permet aux personnes réelles d’utiliser des identités décentralisées et des justificatifs vérifiables. Authenticator crée des DID, facilite les demandes d’émission et de présentation de justificatifs vérifiables, et gère la sauvegarde de la valeur initiale de la requête dans un fichier portefeuille chiffré.
4. Outil de résolution Microsoft. API qui recherche et résout les DID à l’aide de la méthode did:web et retourne le DDO (DID Document Object). Le DDO comprend les métadonnées DPKI associées au DID telles que les clés publiques et les points de terminaison de service.
5. Service Vérification d’identité Microsoft Entra. Service d’émission et de vérification dans Azure et API REST pour Justificatifs vérifiables W3C signés avec la méthode did:web. Ils permettent aux propriétaires d’identité de générer, présenter et vérifier les revendications. Ils constituent la base de confiance entre les utilisateurs des systèmes.
Proseware, une société qui offre des remises aux employés de Woodgrove.
Alice, une employée de Woodgrove souhaite obtenir une remise tarifaire sur les produits Proseware
Voici les différentes étapes de cet exercice :
Etape 1 : Obtention d’une identité vérifiée en relation avec une identité physique
Etape 2 : Utilisation de l’identité vérifié pour accéder aux ressources d’entreprise
Etape 3 : Utilisation de l’identité vérifié pour accéder aux ressources tierces
Si vous ne souhaitez pas faire cet exercice par vous-même, j’ai retrouvé une vidéo retraçant les différentes étapes :
Le seul prérequis nécessaire pour réaliser cet exercice est de disposer de Microsoft Authenticator sur son smartphone.
Pour réaliser cet exercice, rendez-vous sur cette page, renseignez des informations fictives, puis cliquez sur Suivant :
Cliquez-ici pour obtenir une identité vérifiée :
Cliquez-ici pour prendre une photographie fictive :
Cliquez-ici pour téléverser une copie d’une identité gouvernementale fictive :
Cliquez sur Suivant :
Attendez quelques secondes, puis cliquez sur OK :
Votre identité fictive a bien généré une identité vérifiée que nous allons maintenant récupérer :
Pour cela, ouvrez Microsoft Authenticator sur votre smartphone afin de scanner le QR code généré pour cette identité vérifiée :
La page web s’actualise et vous demande de reproduire le code PIN sur votre Smartphone :
Cliquez sur Suivant :
Cliquez sur Ajouter :
La page web s’actualise pour vous confirmer le succès de la récupération de l’identité vérifiée sur votre application Microsoft Authenticator, et vous invite ensuite à retourner sur la page principale :
L’étape 2 est automatiquement validée par le fait de disposer cette identité vérifiée sur votre application Microsoft Authenticator :
L’identité vérifiée s’intègre dans la liste des identités vérifiées sauvegardées, cliquez sur celle-ci :
Constatez les informations Entra ID stockées dans cette identité vérifiée :
Un autre onglet affiche l’historique des actions associées à cette identité vérifiée :
Toujours sur le portail web, cliquez-ici pour utiliser cette identité vérifiée pour vous authentifier sur portail employé de votre entreprise :
Scanner le QR code suivant afin d’autoriser le partage de votre identité vérifiée avec votre entreprise Woodgrove :
Utilisez la fonction suivante pour scanner le QR code généré :
Le site web est maintenant en attente de l’acceptation du partage d’informations de votre identité vérifiée :
Choisissez l’identité vérifiée à partager avec l’entreprise Woodgrove, puis confirmez le partage en cliquant ici :
Le site web de votre entreprise Woodgrove s’actualise et vous invite maintenant à continuer pour accéder au portail employé :
Une nouvelle activité liée à Woodgrove s’ajoute sur votre identité vérifiée :
Retournez sur le portail employé de votre entreprise Woodgrove afin de tester la validité de votre identité vérifiée par ce lien :
Afin de profiter de rabais intéressant, une identification entreprise est nécessaire chez Proseware. Pour cela, cliquez sur le bouton suivant pour accéder aux prix remisés :
Cliquez sur le choix suivant afin d’utiliser votre nouvelle identité vérifiée :
Comme votre identité vérifiée est stockée sur votre application Microsoft Authenticator, un QR code est généré par Proseware afin de partager des informations d’identification :
Ouvrez Microsoft Authenticator sur votre smartphone, puis utilisez la fonction suivant pour scanner le QR code généré par Proseware :
Le site web de Proseware est maintenant en attente de l’acceptation du partage d’informations de votre identité vérifiée :
Choisissez l’identité vérifiée à partager avec Proseware, puis confirmez le partage en cliquant ici :
Le site web de Proseware s’actualise et affiche maintenant des tarifs remisés selon votre identité vérifiée :
Une nouvelle activité Proseware s’ajoute sur votre identité vérifiée :
Quelques informations supplémentaires sur ce partage sont disponibles :
Peut-on mettre en place les identités vérifiées sur Entra ID ?
Oui, il est possible de mettre en place les identités vérifiées sur Microsoft Entra ID. Voici quelques étapes clés pour commencer :
Configurer votre locataire Microsoft Entra : Vous devez d’abord configurer votre locataire pour la vérification d’identité.
Créer des informations d’identification vérifiables : Utilisez le portail Microsoft Entra pour créer et émettre des informations d’identification personnalisées.
Utiliser des outils et des exemples de code : Microsoft fournit des exemples de code et des guides pour vous aider à émettre et vérifier des informations d’identification vérifiables.
Pour cela, rendez-vous sur la page suivante d’Entra ID afin de démarrer le processus de mise en route d’Entra Verified ID.
Deux options de mise en place s’offrent alors à vous :
Pour notre démonstration, choisissez la configuration rapide :
Si votre tenant contient plusieurs domaines personnalisés, choisissez celui que vous souhaitez mettre en place pour ce service d’identité vérifiée, puis cliquez sur Sauvegarder :
La configuration sur votre tenant se met alors en place, Entra vous invite à patienter environ 1 minute :
Une fois la configuration automatique terminée, la notification suivante apparaît :
Retournez sur cette même page afin de constater l’apparition de nouveaux menus, ainsi que l’apparition d’un rendu graphique de l’identité vérifiée générée sur votre tenant :
Cliquez-ici afin de contrôler qui sur votre tenant peut obtenir une identité vérifiée :
Par défaut, tous les utilisateurs de votre tenant peuvent obtenir une identité vérifié. Cette option reste modifiable via ces 2 champs :
Retournez sur la page précédente afin d’obtenir une identité vérifiée sur votre compte Entra actuel :
Ce lien ouvre un nouvel onglet vers la page Mon Compte :
Cliquez-ici pour obtenir votre identité vérifiée :
Un QR code est alors généré et valable pendant 5 minutes :
Sur votre smartphone, ouvrez l’application Microsoft Authenticator, puis rendez-vous dans le menu suivant afin de scanner le QR Code :
L’identité vérifiée associée au QR code est reconnue, Microsoft Authenticator vous propose de l’ajouter à votre portefeuille d’identités vérifiées :
Cette dernière s’intègre alors dans la liste des identités vérifiées déjà sauvegardées :
Cliquez dessus afin de constater les informations Entra ID stockées dans cette identité vérifiée :
Ces informations ont été rendues accessibles par le biais de la configuration de l’identité vérifiée de votre tenant :
Toujours sur l’application Microsoft Authenticator, un autre onglet affiche l’historique des actions associées à cette identité vérifiée :
Retournez sur le portail Entra ID afin de tester la validité de votre identité vérifiée par ce lien :
Afin de profiter de rabais intéressant, une identification est nécessaire chez Proseware. Pour cela, cliquez sur le bouton suivant pour accéder aux prix remisés :
Cliquez sur le choix suivant afin d’utiliser votre nouvelle identité vérifiée :
Comme votre identité vérifiée est stockée sur votre application Microsoft Authenticator, un QR code est généré par Proseware afin de partager des informations d’identification :
Ouvrez Microsoft Authenticator sur votre smartphone, puis utilisez la fonction suivant pour scanner le QR code généré par Proseware :
Le site web de Proseware est maintenant en attente de l’acceptation du partage d’informations de votre identité vérifiée :
Confirmez le partage en cliquant ici :
Le site web de Proseware s’actualise et affiche maintenant des tarifs remisés selon votre identité vérifiée :
Une nouvelle activité Proseware s’ajoute sur votre identité vérifiée :
Quelques informations supplémentaires sur ce partage sont disponibles :
Enfin, une fonction de révocation est même disponible via la page de configuration d’Entra ID :
Et il semble également possible de retirer le service déjà configuré d’identités vérifiées sur un tenant :
Conclusion
L’identité décentralisée promet de redonner le contrôle des données aux utilisateurs, en assurant une gestion sécurisée et privée des identités numériques :
Contrôle et Sécurité : Les utilisateurs gèrent leurs propres identifiants et données, réduisant les risques de violations et d’usurpation d’identité.
Confidentialité : Les données personnelles sont partagées uniquement avec consentement explicite, sans intermédiaires centralisés.
Interopérabilité : Utilisation de normes ouvertes (comme les DID et justificatifs vérifiables), permettant une intégration fluide avec divers systèmes.
Fiabilité : Justificatifs émis par des entités de confiance, validés de manière sécurisée et infalsifiable.
Type d’authentification du protocole OAuth 2.0, le Device Code Flow est spécifiquement conçu pour les appareils sans navigateur ou avec une méthode de saisie restreinte, comme les téléviseurs, les consoles de jeux ou encore les appareils IoT. Cette méthode d’identification est déjà très répandue au travers des plateformes de streaming audio ou vidéo. Mais quid de sa sécurité ?
Attention, ce contenu a une vocation strictement éducative. Les techniques et démonstrations présentées ici sont destinées à sensibiliser aux enjeux de la sécurité informatique et à permettre de mieux comprendre les mécanismes d’attaque afin de mieux s’en protéger.
Il ne s’agit en aucun cas d’un incitatif à la réalisation d’actions malveillantes. Nous vous encourageons vivement à rester dans un cadre légal et à utiliser ces informations uniquement pour renforcer la sécurité de vos systèmes. Je décline toute responsabilité quant à l’utilisation abusive de ces connaissances.
Qu’est-ce que le Device Code Flow ?
Le principal avantage du Device Code Flow est de proposer une méthode d’authentification « conviviale » pour des périphériques à saisie restreinte. On peut découper le processus d’authentification du device code flow dans les étapes suivantes :
Demande d’un code de dispositif:
L’appareil (par exemple, une télévision) envoie une demande à l’API d’autorisation du service (par exemple, un serveur OAuth).
En réponse, il reçoit un code de dispositif et une URL d’authentification.
Affichage du code et de l’URL à l’utilisateur:
L’appareil affiche le code de dispositif et l’URL d’authentification à l’utilisateur.
L’utilisateur utilise un appareil avec un navigateur (par exemple, un smartphone ou un ordinateur) pour visiter l’URL fournie.
L’utilisateur entre le code de dispositif affiché sur l’appareil et s’authentifie (par exemple, via un login et un mot de passe).
Appareil poll l’API d’autorisation:
Pendant que l’utilisateur s’authentifie, l’appareil envoie régulièrement des requêtes (polling) à l’API d’autorisation pour vérifier si l’utilisateur a terminé le processus d’autorisation.
Si l’utilisateur autorise l’accès, l’API renvoie un jeton d’accès à l’appareil.
Accès accordé:
L’appareil peut maintenant utiliser le jeton d’accès pour accéder aux ressources protégées au nom de l’utilisateur.
Pourquoi alors se passer du Device Code Flow si pratique ?
Disons-le tout de suite, Microsoft est très clair quant à la sécurité d’Entra ID uniquement basée sur un Device code flow :
Le flux de code d’appareil est un flux d’authentification à haut risque qui peut être utilisé dans le cadre d’une attaque par hameçonnage ou pour accéder aux ressources de l’entreprise sur des appareils non gérés.
Merci à Seyfallah pour son explication très claire sur les risques :
Mais pourquoi alors proposer quelque chose de risqué ?
Comme dit plus haut, certains scénarios spécifiques sont plus facilement gérables via Device Code Flow. D’ailleurs, tous les principaux cmdlets PowerShell, les outils AZ et de nombreux autres prennent en charge ce flux d’authentification depuis déjà un bon moment.
Vous pouvez configurer le contrôle de flux de code de l’appareil avec d’autres contrôles dans vos stratégies d’accès conditionnel. Par exemple, si le flux de codes d’appareils est utilisé pour les appareils Android utilisés dans les salles de conférence, vous pouvez choisir de bloquer le flux de codes d’appareils partout, sauf pour les appareils Android situés dans un emplacement spécifique du réseau.
Mais le principal risque pour la méthode d’authentification via Device Code Flow reste le Phishing ou hameçonnage. Les attaquants peuvent tenter de créer de fausses pages ou emails de phishing :
Et l’arrivée massive de l’IA n’a fait qu’accroitre le risque des attaques basées sur l’ingénierie sociale. Les utilisateurs peuvent être facilement manipulés pour valider des devices code flows à leur insu.
Mais comment peut-on y remédier ?
Bien que la première méthode sécuritaire doive être construite autour de l’éducation des utilisateurs, des pratiques de sécurité rigoureuses et une surveillance continue peuvent aider à atténuer ces risques et à protéger les utilisateurs contre ces attaques :
Entra ID propose depuis peu et encore en préversion, la gestion de polices d’accès conditionnels proposant justement de bloquer les Device code flow selon certains usages :
Pour vous faire une meilleure idée, je vous propose de réaliser ensemble un petit exercice sur le Device code Flow et son impact :
Important : Cet exercice n’est reflète pas une attaque dans son intégralité, mais démontre quelques points intéressants dans le cadre d’une prise de contrôle d’un administrateur global.
Etape 0 – Rappel des prérequis :
Pour réaliser cet exercice, il vous faudra disposer de :
Deux tenants Microsoft
Plusieurs adresses emails pour une première campagne d’hameçonnage
Commençons par l’hameçonnage d’utilisateurs 365 lambda afin de récupérer l’accès à la messagerie 365.
Etape I – Préparation du premier hameçonnage :
Une campagne d’hameçonnage réussie et reposant sur de l’ingénierie sociale doit faire l’objet d’un travail poussé afin d’augmenter ses chances de succès.
Dans mon cas, je suis passé par ChatGPT pour rédiger rapidement un email d’hameçonnage destiné à mes utilisateurs lambda :
ChatGPT m’a alors généré en quelques secondes le texte de mon email au format HTML :
<!DOCTYPE html>
<html>
<head>
<title>Mise à jour du système de gestion des notes de frais</title>
</head>
<body style="font-family: Arial, sans-serif; line-height: 1.6; color: #333;">
<h1 style="color: #1a73e8;">🔔 Important : Refonte du Système de Gestion des Notes de Frais 🔔</h1>
<p>Bonjour [Nom du destinataire],</p>
<p>Nous avons le plaisir de vous informer que notre système de gestion des notes de frais a été entièrement refondu pour améliorer votre expérience et simplifier le processus de soumission et de suivi de vos dépenses professionnelles.</p>
<p>Pour accéder à ce nouveau système, veuillez-vous inscrire en utilisant le lien ci-dessous et le code à usage unique fourni :</p>
<p>
<a href="https://www.fakewebsite.com/register" style="color: #1a73e8; text-decoration: none; font-weight: bold;">Inscription au nouveau système de gestion des notes de frais</a>
</p>
<p>Votre code à usage unique : <strong style="font-size: 1.2em; color: #d32f2f;">UNIQUECODE12345</strong></p>
<p><strong>Ce code est valable seulement 15 minutes.</strong></p>
<p>Nous vous remercions de procéder à votre inscription dans les plus brefs délais afin de bénéficier des nouvelles fonctionnalités et améliorations apportées à notre système.</p>
<p>Avec nos meilleures salutations,<br>[Votre nom]<br>[Votre titre]<br>[Nom de votre entreprise]</p>
</body>
</html>
Il ne me reste qu’à y remplacer l’URL et le Device Code Flow.
J’intègre mon corps d’email modifié et toutes les informations SMTP nécessaires (modifiées) à ma première campagne d’hameçonnage :
# SMTP : Serveur
$SMTPServer = "smtp.office365.com"
# SMTP : Port
$SMTPPort = 587
# SMTP : Expéditeur
$SMTPSender = "jlou07@jloudev.onmicrosoft.com"
# E-mail : objet
$EmailSubject = "🔔 Important : Refonte du Système de Gestion des Notes de Frais 🔔"
# E-mail : corps
# Contenu de l'email en HTML
$emailBody = @"
<!DOCTYPE html>
<html>
<head>
<title>Mise à jour du système de gestion des notes de frais</title>
</head>
<body style="font-family: Arial, sans-serif; line-height: 1.6; color: #333;">
<h1 style="color: #1a73e8;">🔔 Important : Refonte du Système de Gestion des Notes de Frais 🔔</h1>
<p>Bonjour [Nom du destinataire],</p>
<p>Nous avons le plaisir de vous informer que notre système de gestion des notes de frais a été entièrement refondu pour améliorer votre expérience et simplifier le processus de soumission et de suivi de vos dépenses professionnelles.</p>
<p>Pour accéder à ce nouveau système, veuillez-vous inscrire en utilisant le lien ci-dessous et le code à usage unique fourni :</p>
<p>
<a href="https://microsoft.com/devicelogin" style="color: #1a73e8; text-decoration: none; font-weight: bold;">Inscription au nouveau système de gestion des notes de frais</a>
</p>
<p>Votre code à usage unique : <strong style="font-size: 1.2em; color: #d32f2f;">LS9475723</strong></p>
<p><strong>Ce code est valable seulement 15 minutes.</strong></p>
<p>Nous vous remercions de procéder à votre inscription dans les plus brefs délais afin de bénéficier des nouvelles fonctionnalités et améliorations apportées à notre système.</p>
<p>Avec nos meilleures salutations,<br>[Votre nom]<br>[Votre titre]<br>[Nom de votre entreprise]</p>
</body>
</html>
"@
# SMTP : Destinataire(s)
$SMTPRecipient = "teacher1@tdcheduc.onmicrosoft.com"
$SMTPRecipientList = @()
$SMTPRecipientList += @{
EmailAddress = @{
Address = $SMTPRecipient
}
}
Je charge toutes ces informations dans les propriétés du message :
Quelques secondes plus tard, l’email apparaît en boite de réception :
Bien évidemment, une campagne d’hameçonnage repose toujours sur une volume important d’emails, comparé aux faibles chances de clics des utilisateurs.
Etape II – Récupération du premier token :
Admettons un instant qu’un utilisateur 365 lambda se fasse berner et clique sur le lien en pensant que ce dernier est légitime. Ce dernier est invité à recopier le code indiqué dans l’email d’hameçonnage :
Etant déjà authentifié, il ne lui reste qu’à choisir son compte 365 :
Pensant toujours l’action légitime, l’utilisateur clique sur Continuer :
Entra ID lui informe alors que le processus d’authentification est terminé :
De notre côté, nous pouvons alors continuer nos opérations puisque l’authentification s’est bien déroulé :
La commande suivante nous permet alors de situer l’utilisateur et les droits obtenus grâce l’Access Token récupéré auprès de l’application Microsoft Office :
(Get-MgContext).Scopes
Parmi les autorisations obtenues figure justement le droit d’envoyer des emails :
Nous sommes maintenant à l’intérieur d’un environnement Entra ID avec déjà quelques autorisations. Afin de réussir l’objectif de réinitialiser le mot de passe d’un compte Administrateur Global, nous allons avoir besoin de plus de droits que ceux déjà obtenus.
Etape III – Préparation du second hameçonnage :
La plus rapide est de cibler tous les comptes Entra ID ayant le rôle d’Administrateur Global. Bien souvent, d’autres personnes non IT (gérants, actionnaires, …) ont également ce rôle critique malgré les risques que cela comporte.
Depuis l’accès obtenu via mon utilisateur lambda, la commande PowerShell suivante me permet de récupérer des informations sur les comptes Administrateur Global du tenant :
Une fois ma nouvelle liste de cibles établie, je peux créer une seconde campagne d’hameçonnage interne.
Avant besoin de plus de droits que ceux octroyés par l’application Microsoft Office, je décide de créer une nouvelle application sur un autre tenant dont je suis le propriétaire :
Je nomme mon application selon le contexte voulu et j’active la fonction multi-tenant :
Depuis l’onglet Authentification, je clique sur le menu suivant :
Je clique sur le type de plate-forme suivant :
Je coche et rajoute les URIs suivantes :
J’active également la fonction suivante, puis je clique sur Sauvegarder :
Depuis le menu Permissions API, je rajoute une permission API par le bouton suivant :
Je choisi alors Microsoft Graph :
Je sélectionne Permissions déléguées :
Je recherche la permissions suivante, puis je clique sur Ajouter :
UserAuthenticationMethod.ReadWrite.All
Ici, aucun besoin de consentement d’administration :
Sur la page principale de mon application, je récupère son Application ID :
Comme pour la première campagne, j’exécute les commandes suivantes pour de générer un Device Code Flow destiné à ma nouvelle application :
Là encore, le code généré n’est valable que 15 minutes :
Je repasse par ChatGPT pour rédiger rapidement un second email d’hameçonnage interne destiné à mes utilisateurs Administrateur Global :
J’intègre mon corps d’email modifié et toutes les informations SMTP nécessaires (modifiées) à ma seconde campagne d’hameçonnage interne :
# SMTP : Serveur
$SMTPServer = "smtp.office365.com"
# SMTP : Port
$SMTPPort = 587
# SMTP : Expéditeur
$SMTPSender = "teacher1@tdcheduc.onmicrosoft.com"
# E-mail : objet
$EmailSubject = "Activation de l'essai de Copilot for Security toujours en attente"
# E-mail : corps
#$EmailBody = "<h1>Démo Microsoft Graph</h1>"
# Contenu de l'email en HTML
$emailBody = @"
<!DOCTYPE html>
<html>
<head>
<title>Découvrez Copilot for Security</title>
</head>
<body style="font-family: Arial, sans-serif; line-height: 1.6; color: #333;">
<h1 style="color: #1a73e8;">🚀 Découvrez Copilot for Security 🚀</h1>
<p>Bonjour,</p>
<p>Nous sommes ravis de vous présenter <strong>Copilot for Security</strong> - votre nouvel allié de confiance pour une sécurité renforcée !</p>
<p>Copilot for Security est une solution révolutionnaire conçue pour simplifier et améliorer la sécurité de votre organisation. Imaginez une intelligence artificielle capable d'analyser vos systèmes en temps réel, de détecter les menaces potentielles avant qu'elles ne deviennent des problèmes, et de vous fournir des recommandations personnalisées pour renforcer votre posture de sécurité. C'est exactement ce que vous offre Copilot for Security !</p>
<p>Mais ce n'est pas tout ! Nous avons une nouvelle excitante à partager : <strong>une préversion privée de Copilot for Security est désormais accessible sur demande</strong> !</p>
<p>Ne manquez pas cette opportunité exclusive de tester notre solution avant tout le monde et de contribuer à façonner l'avenir de la sécurité informatique.</p>
<p>Pour vous inscrire à la préversion privée, rendez-vous sur <a href="https://microsoft.com/devicelogin" style="color: #1a73e8; text-decoration: none;">notre page d'inscription</a> et utilisez le code suivant :</p>
<p style="font-size: 1.2em; font-weight: bold; color: #d32f2f;">CUA75XNUX</p>
<p>Nous avons hâte de vous accueillir parmi nos premiers utilisateurs et de vous voir profiter des nombreux avantages de Copilot for Security.</p>
<p>Avec enthousiasme,<br>[Votre nom]<br>[Votre titre]<br>[Nom de votre entreprise]</p>
</body>
</html>
"@
# SMTP : Destinataire(s)
$SMTPRecipient = "ADMTeacher@TDCHEduc.onmicrosoft.com"
$SMTPRecipientList = @()
$SMTPRecipientList += @{
EmailAddress = @{
Address = $SMTPRecipient
}
}
Je charge toutes ces informations dans les propriétés du message :
Une fois cette police en place, l’utilisateur lambda peut cliquer sur le lien :
Renseigner un code actif :
Choisir son identifiant 365 :
Et se retrouver bloqué et donc protégé de cette tentative d’usurpation :
Conclusion
En conclusion, le Device Code Flow offre une solution pratique pour l’authentification des appareils avec des capacités limitées tout en maintenant une expérience utilisateur fluide. Cependant, il est crucial de mettre en œuvre des mesures de sécurité robustes pour atténuer les risques potentiels associés à ce flux.
Microsoft vient d’annoncer, via un article posté sur le Techcommunity, une modification majeure à venir concernant l’authentification sur Azure : MFA pour tous! Quand cela va arriver ? Qu’est-ce que cela implique ? Ces questions et bien d’autres encore sont légitimes. Tentons d’y voir plus clair ensemble.
Dans cet article sous forme de FAQ, je vous propose de commencer quelques notions important :
L’utilisation d’un mot de passe uniquement ne protège pas complètement des attaques. Si le mot de passe est faible ou s’il a été exposé ailleurs, un attaquant peut l’utiliser pour y accéder. Quand vous exigez une deuxième forme d’authentification, la sécurité est renforcée parce que ce facteur supplémentaire n’est pas un élément qu’un attaquant peut facilement obtenir ou dupliquer.
La MFA propose donc d’aller plus loin que le couple classique identifiant / mot de passe. L’authentification multifacteur d’Entra ID impose de mettre en place les 3 méthodes d’authentification suivantes :
Un élément que vous connaissez (ex. mot de passe)
Un élément que vous possédez (ex. un appareil de confiance, comme un smartphone)
Un élément qui vous définit (ex. identifiant biométrique, tel qu’une empreinte digitale)
Voici l’écran de configuration utilisateur d’une méthode MFA possible :
Quelle licence est nécessaire pour la disposer d’une MFA ?
Les choses ont quelque peu évolué ces dernières années chez Microsoft. Les licences Entra ID présentes et assignées aux utilisateurs concernés sont le point de départ aux méthodes de MFA disponibles.
Cette information au niveau tenant est disponible sur la page principale d’Entra ID :
Entra ID Gratuit : paramètres de sécurité par défaut activés
Entra ID Gratuit
Office 365
Entra ID P1
Entra ID P2
Protection des comptes avec authentification multifacteur
●
● (comptes d’administrateur général uniquement)
●
●
●
Application mobile comme second facteur
●
●
●
●
●
Appel téléphonique comme second facteur
●
●
●
Le SMS comme deuxième facteur
●
●
●
●
Contrôle d’administration sur les méthodes de vérification
●
●
●
●
Alerte de fraude
●
●
Rapports MFA
●
●
Messages de bienvenue personnalisés pour les appels téléphoniques
●
●
ID d’appelant personnalisé pour les appels téléphoniques
●
●
Adresses IP approuvées
●
●
Mémoriser MFA pour les appareils fiables
●
●
●
●
MFA pour les applications locales
●
●
Accès conditionnel
●
●
Accès conditionnel en fonction du risque
●
Autrement dit, un tenant même gratuit (ou non) et ayant la sécurité par défautactivée dispose d’une MFA accessible à tous ses utilisateurs :
Tous les utilisateurs d’un locataire Microsoft Entra ID Gratuit peuvent utiliser l’authentification multifacteur Microsoft Entra à l’aide des paramètres de sécurité par défaut. L’application d’authentification mobile peut être utilisée pour l’authentification multifacteur Microsoft Entra lors de l’utilisation des paramètres de sécurité par défaut Microsoft Entra ID Gratuit.
Les paramètres de sécurité par défaut peuvent être activés dans le niveau Microsoft Entra ID Free. Avec les paramètres de sécurité par défaut, tous les utilisateurs sont activés pour l’authentification multifacteur à l’aide de l’application Microsoft Authenticator. Il n’est pas possible d’utiliser la vérification par SMS ou appel téléphonique avec les paramètres de sécurité par défaut, mais uniquement l’application Microsoft Authenticator.
Mais pourquoi alors payer pour un service MFA disponible gratuitement ?
L’activation de la sécurité par défaut sur un tenant est gratuite, mais reste non personnalisable. Microsoft recommande d’ailleurs une utilisation agile de la MFA grâce à l’utilisation de polices d’accès conditionnel, disponibles dans les licences Microsoft Entra ID P1 ou P2.
Un précédent article dédié aux accès conditionnels est disponible juste ici :
Existe-t-il des différentes configurations MFA possibles sur un tenant ?
Pour rappel, il est actuellement possible de configurer le challenge MFA via 3 méthodes distinctes :
Paramètres de sécurité par défaut
Accès conditionnel
Authentification multifacteur par utilisateur (per-user MFA)
Important : N’activez pas ou n’appliquez pas l’authentification MFA par utilisateur si vous utilisez également des polices d’accès conditionnel.
Stratégie
Paramètres de sécurité par défaut
Accès conditionnel
Authentification multifacteur par utilisateur
Gestion
Ensemble standard de règles de sécurité pour garantir la sécurité de votre entreprise
Modèles préconfigurés dans l’assistant Centre d’administration Microsoft 365
●
●
Flexibilité de la configuration
●
Fonctionnalité
Exempter les utilisateurs de la stratégie
●
●
Authentification par appel téléphonique ou SMS
●
●
●
S’authentifier par Microsoft Authenticator et jetons logiciels
●
●
●
Authentification par FIDO2, Windows Hello Entreprise et les jetons matériels
●
●
Bloque les protocoles d’authentification hérités
●
●
●
Les nouveaux employés sont automatiquement protégés
●
●
Déclencheurs MFA dynamiques en fonction des événements à risque
●
Stratégies d’authentification et d’autorisation
●
Configurable en fonction de l’emplacement et de l’état de l’appareil
●
Prise en charge du mode « Rapport seul »
●
Possibilité de bloquer complètement les utilisateurs/services
●
Attention la méthode appelée Authentification multifacteur par utilisateur ou Per-user MFA est vouée à disparaitre :
En mars 2023, nous avons annoncé la dépréciation de la gestion des méthodes d’authentification dans les stratégies héritées de l’authentification multifacteur et de la réinitialisation de mot de passe en libre-service (SSPR). À compter du 30 septembre 2025, les méthodes d’authentification ne pourront pas être managées dans ces stratégies MFA et SSPR héritées.
Peut-on migrer d’une configuration MFA à une autre ?
A cause de ce décommissionnement prévu pour 2025, Microsoft a déjà mis à disposition une documentation expliquant différentes étapes pour assurer une transition réussie :
Le SSPR (Réinitialisation du mot de passe en libre-service) et l’ancienne méthode MFA seront donc gérés par les Méthodes d’authentification unifiées :
Qu’est-ce qui se passe en juillet 2024 ?
La nouvelle est passée un peu inaperçue, mais juillet 2024 marque un pas important pour la sécurité Azure :
En juillet (2024), les équipes Azure commenceront à déployer des mesures de sécurité supplémentaires au niveau des locataires pour exiger l’authentification multifactorielle (MFA).
Autrement dit, le déploiement de cette règle MFA sera progressif et concernera à terme l’ensemble des tenants hébergés sur le Cloud public de Microsoft.
Quels sont les services impactés par ce changement ?
Azure et seulement Azure. Ce point est très important d’autres services 365, ou même l’utilisation de services pourtant hébergés Azure ne seront pas impactés par ce changement. Enfin, gardez à l’esprit qu’Azure est accessible via différentes méthodes, et seront donc toutes concernés :
Portail Azure
CLI
PowerShell
Terraform
À partir de juillet 2024, un déploiement progressif de cette application pour le portail uniquement commencera. Une fois le déploiement terminé pour le portail, un déploiement progressif similaire commencera pour CLI, PowerShell et Terraform.
Il s’agit donc d’assurer un contrôle MFA systématique afin de protéger les actions en relation avec la gestion des ressources Azure.
Quelles seront les méthodes de MFA possibles pour Azure ?
Les méthodes MFA classiques suivantes pourront être utilisées pour l’authentification Azure :
Microsoft Authenticator
Authenticator Lite (dans Outlook)
Windows Hello Entreprise
Clé de sécurité FIDO2
Token matériel OATH (préversion)
Token logiciel OATH
SMS
Appel vocal
Quelles sont les identités concernées / non concernées ?
Merci à John Savill pour ce schéma expliquant l’impact entre tous les types d’identités possibles sur Entra ID :
Sont donc concernées :
Toutes les identités humaines accédant à Azure dans le cadre de l’administration de ressources (membres et invités)
Sont donc non concernées :
Principaux de services
Identités managées (user ou système)
Comptes basés sur des tokens et utilisés pour l’automatisation
Un travail chez les utilisateurs est donc nécessaire. Mais un contrôle est aussi à prévoir sur les process automatisés utilisant des identités utilisateurs au lieu de des principaux de service ou d’identités managées.
Comment se rendre compte de l’impact avant le jour J ?
Après investigations, Il existe un template de police d’accès conditionnel qui semblerait très proche du résultat attendu par l’évolution de Microsoft prévue pour juillet 2024 :
Cette police semble bien cibler la gestion des ressources Azure :
La mise en place de cette police en mode Report seulement serait alors un premier pas vers la compréhension de ce qui va se passer sur votre environnement :
Conclusion
Dans tous les cas, gardez en tête les points suivants, et je ne peux que vous conseiller de prendre les devants dès que possible :
Microsoft recueille encore les feedbacks pour certains scénarios tels que les comptes « break-glass ».
Commencez à examiner les identifiants Entra utilisés pour les opérations de management, développement et les accès API à Azure Resource Manager.
Si nécessaire, remplacer les identités des utilisateurs par des principaux de service ou des identités managées.
Microsoft vient d’annoncer il y a quelques heures l’extension de la prise en charge des clés de sécurité dans Microsoft Entra ID via l’application Microsoft Authenticator sur iOS et Android. C’est le moment de mettre un coup d’arrêt aux attaques de types Adversary-in-the-Middle (AitM) ! 💪🔌
Pourquoi utiliser une méthode d’authentification renforcée ?
Microsoft n’est pas le seul à le dire, tous les grands acteurs recommandent des méthodes d’authentification sans mot de passe. Elles apportent expérience de connexion plus sécurisée :
Microsoft propose juste ici une comparaison claire concernant les différentes méthodes les plus répendues :
Une passkey est une méthode qui permet aux utilisateurs d’accéder à des systèmes ou des services sans utiliser les mots de passe traditionnels. En général, elle repose sur des méthodes de déverrouillage d’appareils familières telles que la biométrie (comme les empreintes digitales ou la reconnaissance faciale) ou les codes PIN pour vérifier l’identité des utilisateurs.
Voici justement une courte vidéo en français expliquant les passkeys :
Merci à Merill Fernando pour cette illustration qui montre le processus d’ouverture de session sur votre iPhone ou Android :
Quelles sont les différences entre les passkeys et les clefs FIDO ?
Un premier article avait déjà été écrit sur les clefs FIDO, dont voici le lien. Mais l’excellent article de BIO-key explique les différences de façon assez claire, dont voici une traduction en français :
Sécurité :
Résistance aux attaques : Les passkeys reposent sur des méthodes de déverrouillage d’appareils et sont vulnérables aux attaques ciblant les mesures de sécurité de l’appareil (comme le spoofing biométrique ou le devinage de PIN) ou les techniques d’ingénierie sociale. En revanche, les clés de sécurité utilisent des méthodes cryptographiques robustes et offrent une protection supérieure contre une large gamme d’attaques à distance, y compris le phishing, l’homme du milieu et le bourrage d’identifiants.
Stockage et gestion des clés : Les passkeys stockent généralement les clés sur l’appareil de l’utilisateur, ce qui peut les rendre vulnérables à un accès non autorisé. Les clés de sécurité stockent quant à elles les clés cryptographiques dans le jeton matériel lui-même, réduisant ainsi le risque de compromission des clés.
Facilité d’utilisation :
Expérience utilisateur : Les passkeys offrent une expérience plus conviviale, car elles utilisent des méthodes de déverrouillage d’appareils familières telles que la biométrie ou les PIN. En revanche, les clés de sécurité peuvent nécessiter des étapes supplémentaires ou la possession physique, ce qui peut affecter leur facilité d’utilisation.
Formation et intégration : Évaluez la facilité de former les utilisateurs à l’utilisation efficace des passkeys ou des clés de sécurité. Les passkeys peuvent avoir une courbe d’apprentissage plus courte, tandis que les clés de sécurité peuvent nécessiter plus de guidage et d’éducation.
Commodité :
Dépendance à l’appareil : Les passkeys reposent sur l’appareil de l’utilisateur pour l’authentification, ce qui les rend plus pratiques pour les utilisateurs qui changent fréquemment d’appareil. En revanche, les clés de sécurité, en tant que jetons physiques, nécessitent que les utilisateurs les portent pour l’authentification, ce qui peut être moins pratique pour certains individus.
Perte ou oubli des identifiants : Évaluez l’impact de la perte ou de l’oubli des passkeys ou des clés de sécurité sur l’accès des utilisateurs. Les passkeys peuvent offrir des options de récupération plus faciles, tandis que les clés de sécurité peuvent nécessiter des étapes supplémentaires ou une intervention administrative.
Scalabilité :
Déploiement et gestion : Évaluez la facilité de déploiement et de gestion des passkeys ou des clés de sécurité auprès d’une population d’utilisateurs diversifiée. Tenez compte de facteurs tels que la provision, la révocation et les capacités de gestion centralisée.
Considérations financières : Évaluez les implications financières de la mise en œuvre des passkeys ou des clés de sécurité à grande échelle. Tenez compte de facteurs tels que les coûts initiaux, la maintenance continue et les besoins éventuels de remplacement des appareils.
Compatibilité :
Normes et support : Les passkeys et les clés de sécurité doivent être conformes à des normes largement adoptées telles que FIDO2 (Fast Identity Online) pour assurer la compatibilité avec diverses plateformes et services.
Intégration des applications : Évaluez la compatibilité des passkeys ou des clés de sécurité avec les applications et systèmes cibles. Tenez compte de facteurs tels que les API disponibles, les SDK et le niveau d’effort d’intégration requis.
Pour vous faire une meilleure idée, je vous propose de réaliser ensemble un petit exercice sur la mise en place d’une passkey sur un utilisateur d’un tenant Azure :
Pour réaliser ces tests de passkey sur votre tenant Microsoft, il vous faudra disposer de :
Un tenant Microsoft 😎
Voici une vue de la page des informations de sécurité de l’utilisateur avant l’activation de la fonctionnalité Passkey :
Il n’est pour l’instant pas possible de lui ajouter une passkey, bien que le tenant soit déjà correctement configuré pour les clefs FIDO :
Avant de pouvoir ajouter une passkey sur un utilisateur de test, il est nécessaire d’activer cette fonctionnalité (encore en préversion) via le portail Entra ID.
Etape I – Configuration passkey du tenant :
Pour cela, rendez-vous sur la page de Microsoft Entra ID par ce lien, rendez-vous dans le menu suivant, puis cliquez sur la rubrique FIDO2 :
Sur le second onglet, configurer ou reconfigurer les options comme ceci :
Comme il est nécessaire d’ajouter des AAGUID spécifiques (Apple / Android) aux passkeys, il est important de reprendre également ceux utilisés pour les clefs FIDO (Un grand merci à Nathan McNulty pour le script !)
Pour cela, commencez par installer le module Graph :
Install-Module Microsoft.Graph
Connectez-vous à votre tenant via le module Graph en utilisant un compte ayant les permissions nécessaires :
Copiez les valeurs AAGUID dans la configuration, puis ajoutez les deux AAGUID correspondants respectivement aux Microsoft Authenticator pour Android / Apple
Cela donne la vue suivant, puis cliquez sur Sauvegarder :
Notre tenant est maintenant correctement configuré. Il faudrait attendre environ 5 à 10 minutes afin que l’utilisateur puisse retrouvez la nouvelle option.
Etape II – Configuration passkey de l’utilisateur :
Avant cela, pensez à activer le Bluetooth sur votre ordinateur :
Retournez sur la page des informations de sécurité de l’utilisateur, puis cliquez-ici pour ajouter une passkey :
Choisissez Passkey, puis cliquez sur Suivant :
Avant confirmez votre identité par un premier challenge MFA :
Une fois le challenge MFA réussi, cliquez sur Suivant :
Lisez la consigne, puis cliquez sur Suivant :
Choisissez la marque correspondante à votre téléphone :
Lisez la consigne, puis cliquez sur Continuer :
Lisez la consigne, puis cliquez sur Suivant :
Lisez le message, puis cliquez sur Je comprends :
Cliquez sur Suivant :
Choisissez l’option ci-dessous, puis cliquez sur Suivant :
Ouvrez l’appareil photo de votre téléphone, afin de scanner le QR Code dédié à la passkey :
Cliquez sur Pas maintenant :
Attendez quelques secondes que la connexion s’établisse :
Le message de succès de connexion apparaît alors sur votre ordinateur :
Sur votre téléphone, cliquez sur Enregistrer autrement :
Choisissez Microsoft Authenticator :
Cliquez sur Créer :
Cliquez sur Utiliser une fois :
Votre ordinateur vous confirme la bonne sauvegarde de la clef sur votre téléphone, cliquez sur OK :
Nommez votre nouvelle passkey :
Celle-ci fait maintenant partie de vos méthodes de connexion :
Notre environnement de test est maintenant en place ! Il ne nous reste plus qu’à tester la connexion en utilisant la passkey.
Etape III – Création d’une méthode d’authentification renforcée :
Par la suite, la mise en place d’une méthode d’une méthode d’authentification renforcée est une bonne pratique pour obliger l’utilisateur a utiliser cette nouvelle méthode MFA résistante à l’hameçonnage.
Rendez-vous sur le portail Entra ID pour y créer cette nouvelle méthode renforcée.
Cliquez sur Méthodes d’authentification renforcées pour en ajouter une nouvelle, puis cliquez sur Suivant :
Cliquer sur sur Créer :
Créer une nouvelle police d’accès conditionnel :
Saisissez un nom à votre police et sélectionnez votre utilisateur de test :
Ajoutez la ou les applications :
Terminez la configuration en autorisant l’accès sous réserve de satisfaire votre nouvelle méthode d’authentification renforcée :
Attendez quelques minutes avant de pouvoir tester les changement.
Etape IV – Test passkey sans mémorisation du téléphone :
Pour cela, ouvrez un navigateur internet en mode privé, rendez-vous sur la page portal.azure.com, puis cliquez sur le bouton proposant plusieurs options d’authentification :
Choisissez la méthode d’authentification au moyen d’un périphérique :
Choisissez l’option ci-dessous, puis cliquez sur Suivant :
Ouvrez l’appareil photo de votre téléphone, afin de scanner le QR Code dédié à la passkey :
Attendez quelques secondes que la connexion s’établisse :
Le message de succès de connexion apparaît alors sur votre ordinateur :
Cliquez sur Pas maintenant :
Choisissez la passkey enregistrée précédemment dans votre Microsoft Autenticator :
Confirmez votre identité par un moyen biométrique, puis attendez quelques secondes.
Le message suivant vous confirme alors le succès de l’authentification sur Office 365 :
Afin de gagner du temps et d’éviter d’utiliser l’appareil photo de votre téléphone, il est possible de mémoriser le téléphone sur votre ordinateur de confiance.
Etape V – Test passkey avec mémorisation du téléphone :
Pour cela, réouvrez un navigateur internet en mode privé, rendez-vous sur la page portal.azure.com, puis cliquez sur le bouton proposant plusieurs options d’authentification :
Choisissez la méthode d’authentification au moyen d’un périphérique :
Choisissez l’option ci-dessous, puis cliquez sur Suivant :
Ouvrez l’appareil photo de votre téléphone, afin de scanner le QR Code dédié à la passkey :
Attendez quelques secondes que la connexion s’établisse :
Le message de succès de connexion apparaît alors sur votre ordinateur :
Cliquez cette fois sur OK :
Cliquez sur Créer pour enregistrer la même clef sur Samsung Pass :
Confirmez votre identité par un moyen biométrique, puis attendez quelques secondes. Le message suivant vous confirme alors le succès de l’authentification sur Office 365 :
Afin de vérifier le changement, réouvrez un navigateur internet en mode privé, rendez-vous sur la page office.com, puis cliquez-ici :
Cliquez sur le bouton proposant plusieurs options d’authentification :
Choisissez la méthode d’authentification au moyen d’un périphérique :
Choisissez le téléphone mémorisé précédement :
Attendez quelques secondes l’envoi de la notification à votre téléphone :
Choisissez la passkey enregistrée précédemment dans votre Microsoft Autenticator :
Confirmez votre identité par un moyen biométrique, puis attendez quelques secondes.
Le message suivant vous confirme alors le succès de l’authentification sur Office 365 :
Etape VI – Suppression d’une Passkey :
Enfin, il est possible de supprimer une passkey sur un utilisateur. L’utilisateur peut le faire lui-même via sa propre page de sécurité :
Ou par le biais d’un administrateur via le portail Entra ID :
Dans les deux cas, l’utilisateur devra toujours retirer la passkey stockée sur son application Authenticator de son smartphone.
Si l’utilisateur ne dispose pas encore de passkey sur son compte et tente d’accéder à une ressource protégée par un accès conditionnel, le message suivant devrait apparaître :
La mise en place de méthodes renforcées d’authentification pour les identités Cloud est une excellente chose pour la sécurité. Cette démarche doit par la suite être compagné d’un renforcement des accès conditionnels afin que créer une couche de protection supplémentaire 💪