Plus des trois quarts (78 %) des organisations utilisant les services de Microsoft Azure Active Directory (AD) n'utilisent pas l'authentification multifacteur (MFA) pour leurs comptes d'utilisateurs, selon une nouvelle télémétrie du service Azure Active Directory de Microsoft, constate DarkReading.
Ce pourcentage est d'autant plus déplorable qu'en 2021, Azure Active Directory a détecté et bloqué plus de 25,6 milliards de tentatives de force brute sur les comptes utilisateurs, et que « 99,9% des violations seraient évitées si vous implémentiez simplement l'authentification multifacteur », précise le CISO de Microsoft, Bret Arsenault.
« Pourquoi se donner la peine d'essayer de contourner MFA alors qu'il existe des comptes qui ne nécessitent qu'un nom d'utilisateur et un mot de passe ? », demande Brett Winterford, directeur principal de la stratégie de cybersécurité chez Okta, qui a découvert que les attaquants ciblent les comptes Microsoft 365 non protégés par MFA 10 fois plus que les autres.
« Les contrôleurs de domaine [tels que AD] sont la cible principale des acteurs de ransomware. À partir de ce serveur, l'attaquant peut découvrir et accéder à tous les appareils du réseau et très rapidement arrêter une organisation », explique Winterford. « Nous lisons régulièrement des rapports de groupes de ransomwares passant d'un seul compte compromis à un administrateur de domaine en quelques heures. »
Commentaires (26)
#1
Hmmm je n’ai pas vu (pas trop cherché à vrai dire) cette option disponible sous un AD 2019 standard. Est-ce que cela ne serait pas réservé que pour AzureAD ?
#1.1
C’est disponible On Prem, mais il faut en général une solution tiers pour le 2eme facteur.
La doc en cite certains: https://docs.microsoft.com/en-us/windows-server/identity/ad-fs/operations/configure-additional-authentication-methods-for-ad-fs
#1.2
Ton lien est pour AD FS, pas AD.
D’ailleurs le titre et le premier paragraphe sont faux puisqu’il ne s’agit pas d’AD mais d’Azure AD comme dit dans le doc microsoft :
https://news.microsoft.com/wp-content/uploads/prod/sites/626/2022/02/Cyber-Signals-E-1.pdf
Ce qui explique aussi pourquoi ca parle d’okta dans la news qui permet notamment de faire de la fédération mais n’a rien à voir avec AD on premise.
Par contre y’a une notion de DC dans azure AD ? Vrai question je connais pas azure AD.
#1.3
Tu mets AD FS par dessus ton AD On Prem. Et ça fait le boulot. Cela ne s’applique pas uniquement à Azure AD. C’est ce qu’on utilise dans ma boite pour l’authentification multi facteur de certains services. Sans qu’Azure AD n’ait quoi que ce soit à voir avec le tout.
Et on utilise bien un des services qui est dans la liste. Déployé On Prem aussi.
#1.4
Tu peux faire de la double auth avec un AD on prem sans aucun services dans le cloud avec uniquement des services Microsoft ?
#1.5
Tu peux le faire sans le cloud.
Avec uniquemement du Microsoft, je ne pense pas vu que dans la liste des solutions approuvées la leur est Azure AD.
Mais on a deux services tiers de cette liste pour le 2FA chez nous, pour deux usages distincts, branchés par dessus l’AD. On est 100% On Prem.
#2
Et alors ?
ils veulent imposer la double authentification pour récupérer encore plus d’info ?
Le jour ou je verrais qu’un mot de passe unique et fort est un point faible, je serais partisant de la double authentification, d’ici la, c’est juste un moyen d’obliger les gens à donner leur numéro de téléphone sous couvert d’augmenter la sécurité alors que concentrer tout sur un smartphone est pire que d’avoir un gestionnaire de mot de passe sur un PC fixe.
#2.1
Il me semble qu’ils proposent une autre possibilité que le SMS.
Pour les comptes Microsoft j’utilise l’application Authy.
Pour une fois, il ne faut pas voir le mal partout. Microsoft est une cible privilégiée des attaques. Mettre une plus forte sécurité diminue de fait les attaques. Ce qui diminue leurs coûts (bande passante, ressource, …).
#2.2
Tu n’es pas obligé de donner ton numéro de téléphone. Il ya d’autres possibilités comme les applications de MFA (MS Authenticator, Google Authenticator, Authy, etc.), des clés FIDO, des cartes à puces, voire du conditional access avec des machines dans Intune ou des certificats. En fait les solutions de SMS sont là pour les gens qui ne veulent pas mettre en place autre chose, mais c’est la solution de MFA la moins sécurisée.
Et il faut arrêter de penser que MS veut récolter tes données à tout va pour les exploiter à des fins commerciales (à des fins d’IA je ne dis pas), surtout pour de l’AAD professionnel.
Et si un mot de passe robuste est bon, tu en as combien des mots de passe robustes ? Parce qu’il n’y a pas que Windows dans la vie, et tout le monde n’a pas un gestionnaire de mots de passe. Si tu savais le nombre de gens qui utilisent les même mots de passe partout, ou qui se le font prendre par du phishing. Le MFA aide à lutter contre ça.
edit : grilled
#2.3
C’est un troll, rassure moi ?
#3
Le titre est trompeur. Il s’agit bien d’Azure AD (AAD) qui n’a pas grand chose à voir avec Active Directory services - Le service disponible sur Windows Server en dehors de sa parentalité à Microsoft.
AAD dispose notamment d’un service d’accès conditionnel absolument vital dans un contexte externalisé supportant nativement le MFA. C’est d’autant plus déplorable que Microsoft a fait un travail intéressant pour l’évaluation de sa posture sécurité dans Azure : T’es plutôt bien mis au courant et guidé pour mettre ce genre de fondamentaux en place.
#4
Connaissant les utilisateurs, si on se met à faire du MFA, ca serait un carnage pour la connexion
A ce que j’en comprends ici, il faut juste un AzureMFA, pas besoin d’AzureAD.
#5
Tout à fait. Pour ADDS, le classique est comme indiqué par letter l’ajout d’un plugin sur ADFS (lorsqu’on en dispose). Il existe plus rarement des solutions intégrables comme Silverfort mais la plupart vont nécessiter un agent dont la robustesse est souvent à chier.
#6
Ce service est déprécié et remplacé par Azure AD MFA qui conditionne l’usage on-prem par un déploiement en mode hybride ADDS + AAD. Donc dans tous les cas, tu dois avoir un déploiement assez significatif dans Azure et donc l’existence d’un AAD.
#7
Beaucoup d’assertions, peu de tangible.
Le contexte de la publication est Enterprise, mais cela peut s’appliquer aussi à la vie quotidienne privée.
Toute la littérature sur le sujet démontre en effet que l’authentification simple est critique, tu as deux études dans le brief qui le démontrent. Si tu as l’occasion d’échanger avec des SOC/CERT, tu comprendras combien le MFA est ultra important pour combattre le phishing, le password spray, les annuaires dispo sur le “dark net” pour quelques centaines de $ …
Si l’identité est le fer de lance de la stratégie en sécurité de beaucoup d’entreprises et de fournisseurs de solutions, c’est pas pour rien.
En contexte pro, tu as un tel pro (ou un token physique associé). Quel problème que MS récupère le numéro de téléphone ?
En contexte perso, généralement le téléphone est donné à la création du compte pour pouvoir reset le mot de passe; tu peux donner un faux, mais tu peux aussi ne pas arriver à prouver au support que tu es le possesseur légitime et donc perdre ton compte.
“Concentrer la sécurité sur un téléphone est pire que d’avoir un gestionnaire de mot de passe sur un PC fixe.”
Après, si tu compares une solution de MFA à un password manager, c’est que tu ne comprends pas les concepts.
Le fait d’utiliser un composant tierce permet justement de découpler la sécurité en répartissant les risques, tu ne concentres rien.
Rien ne t’empêche d’utiliser un mot de passe fort, et d’y ajouter une validation humaine à chaque fois. En quoi c’est moins sécurisé ?
J’ai le MFA de systématiquement activé sur tous les services que je peux, et maintenant la question du mot de passe est accessoire. Et je n’ai plus les problèmes de sécurité sur Steam/FB/Blizzard que j’ai pu rencontré avant.
#8
Merci aux commentateurs ci-dessus d’avoir débunké le titre de NXI.
Je commençais a me demander si c’était Microsoft qui faisait du FUD pour pousser les entreprises à migrer leur gestion d’utilisateur sur Azure.
#9
Je ne vois pas en quoi la double authentification est plus sécurisé qu’un verrouillage de compte au delà de 3 ou 5 erreurs.
#9.1
Avoir une alerte et une capacité de alerte/décision quand quelqu’un essaye de se connecter à des services qui peuvent être critiques (données, identité, finance …) est bien plus souple et immédiat qu’un verrouillage. Lequel ne serait d’ailleurs qu’une horreur à gérer pour les personnes pas forcément à l’aise avec l’informatique, et qui ne verraient pas forcément les problèmes de sécurité en découlant.
En choisissant la bonne solution, le comportement est simple à donner à des personnes pas forcément à l’aise avec l’IT : “tu reçois une notification de connexion sur ton tel, est-ce que c’est toi ou ton conjoint qui vient de s’identifier ? Si non, ou si tu sais pas, tu déclines”
C’est le principe du 3DSecure pour les cartes bancaires, et je ne vois pas souvent des gens s’en plaindre.
ça permet à l’utilisateur de rester actif pour sa protection, et de ne pas juste rester passif en attendant que les problèmes arrivent; et c’est une bonne chose pour que les populations montent progressivement en compétences et limitent par la même les impacts des attaques.
#9.2
Oui mais s’il ne fait aucune erreur, l’attaquant arrive à accéder au compte sans encombre. Au hasard, avec du phishing ou la récupération de mots de passe depuis des applications qui les gardent en clair de manière non protégée.
Et crois-moi, ces deux cas sont plus fréquents que tu ne le penses. Même chez des utilisateurs avertis (même si c’est moins le cas chez eux).
#10
A la décharge de NXI, l’article original auquel ils font référence crée la même confusion. C’est d’autant plus étrange qu’il n’est pas possible d’avoir des statistiques sur l’usage du MFA dans un environnement on-prem (Et toutes leurs données concernent Azure AD).
#11
Trop de techniques efficaces permettent encore de récolter des mots de passe valables en s’attaquant à LSASS et/ou la mémoire du système. (Quand c’est pas une appli foireuse qui l’offre sur un plateau) Ni le verrouillage ni une politique de mot de passe agressive n’est une solution ici.
Tu peux par contre viser le passwordless en remplacement du MFA pour enrayer le problème. On utilise par exemple massivement Windows Hello for Business pour limiter à mort l’usage du pass. Mais là encore les applications risquent vite de limiter ton impact.
#12
On parle du LDAP, l’authentification se fait au niveau de l’OS. De plus il s’agit généralement de machines dédiées entreprise avec des profils restreints. On peut même implémenter du NAC pour s’assurer que la machine dispose du certificat adéquat pour se connecter au réseau.
C’est géré comme ça depuis les années 2000 sur les SIG important.
Les erreurs d’authentification sont loggées par le service AD et avec une solution de corrélation il est possible d’avoir des alertes rapidement.
C’est le principe de la CB depuis des années et c’est efficace même avec un code à 4 chiffres.
#13
On parle de Active Directory, il s’agit du login/pass pour accéder au système d’exploitation.
Il est difficile de simuler la première connexion à un PC pour effectuer un fishing.
Et je suppose que MS ne stock plus les données d’authentification en clair (même si c’était effectivement le cas sous NT4).
#14
Avec Mimikatz & co, j’ai l’impression que certains ne comprennent pas l’importance de prouver la légitimité de la connexion…
C’est pas pour rien que MS pousse à utiliser des Pin avec windows Hello…
MFA C’est pas un gadget…
https://docs.microsoft.com/en-us/windows/security/identity-protection/hello-for-business/hello-why-pin-is-better-than-password
#15
Quelle plaie ces auth 2 facteurs !
Le pire avec Azure est qu’une fois coché la case pour tester tu ne peux plus revenir en arrière !
C’est insupportable une prise en otage de tes données personnelles !
#16
Oui ça c’est une solution, la sécurité ne doit consister en une contrainte sur l’utilisateur : mots de passe trop complexes à changer tous les xxx jours.
Ça ne fait que baisser la sécurité le mot de passe devient impossible à mémoriser donc il est stocké ou suit une logique devinable.
2 facteurs quand le deuxième facteur est sur le même terminal : C’est contre-productif, ça n’apporte aucune sécurité en cas de vol de tel par ex, et pire ça apporte un sentiment de sécurisation qui va pousser à mettre un mot de passe plus simple (j’ai mis 1234 en mot de passe, je ne risque rien y’a le 2FA !)
Généraliser et imposer (au service tiers) le SSO couplé à un service d’auth fort (carte à puce, token…) ça permet de sécurisé grandement l’accès et simplifié la vie des utilisateurs: Un mot de passe unique voir aucun, en cas de départou incident de sécurité, les accès sont centralisés à un seul accès (pas de risque d’oublier de locker un login/mdp dans une app quelconque…)
La menace ce ne sont pas les utilisateurs qui mettent un mot de passe trop simple, mais les RSSI qui font les mauvais choix et poussent les utilisateurs à en arriver là !