Aujourd'hui, toute organisation possède un annuaire LDAP rempli d'utilisateurs de cette organisation. Si vous regardez attentivement, vous trouverez une ou plusieurs applications qui utilisent le même répertoire pour «l'authentification». Et les guillemets ne sont pas accidentels ici, car LDAP est un protocole d'accès à l'annuaire conçu pour lire, écrire et rechercher le service d'annuaire. Ce n'est pas un protocole d'authentification. Le terme «authentification LDAP» fait plutôt référence à cette partie du protocole (opération de liaison), qui détermine qui vous êtes et quels droits d'accès vous avez aux informations de l'annuaire.
Au fil du temps, LDAP est devenu un service d'authentification de facto. Les services LDAP généralisés et abordables, tels que Active Directory, sont devenus une friandise pour les développeurs de logiciels qui souhaitent intégrer l'authentification dans leurs produits. Les bibliothèques clientes LDAP sont disponibles pour presque tous les frameworks et l'intégration est relativement facile à implémenter.
Mais malgré le fait que l'utilisation de LDAP puisse aider à résoudre le problème de l'implémentation de l'authentification des utilisateurs dans diverses applications de l'entreprise, cela crée de nombreux problèmes. Contrairement aux protocoles d'authentification spécialement conçus, l'utilisation de LDAP entraîne diverses vulnérabilités de sécurité des informations.
Pour comprendre quelles sont ces vulnérabilités, vous devez d'abord comprendre le fonctionnement de l'authentification LDAP.
Fonctionnement de l'authentification LDAP
Imaginez la situation suivante (elle est loin de la réalité, mais elle transmet parfaitement l'essence).
Supposons que je passe une commande dans une boutique en ligne afin qu'elle soit livrée à mon domicile en mon absence. Le courrier arrive et laisse une note sous la porte avec le texte «Je suis désolé, nous ne vous avons pas trouvé» et me demande de retirer la commande au point de retrait le plus proche à un moment opportun. Au point de prise en charge, l'employé me demande mon nom, mon adresse et demande les clés de la maison pour confirmer mon identité. Ensuite, l'agent de livraison vient chez moi et ouvre la porte avec ma clé. Il va à l'intérieur pour s'assurer que j'habite là-bas, par exemple, à partir de photographies sur le mur ou par le nom du destinataire sur la correspondance. Après cela, l'employé revient au point d'émission et m'informe qu'il a réussi à confirmer mon identité, et je peux recevoir mon colis! Hourra!
En plus des problèmes de logistique, cette situation regorge d'autres problèmes. Et si un critique sans scrupules faisait une copie de ma clé? Ou a-t-il laissé la clé sans surveillance pendant longtemps, et quelqu'un d'autre? Et si le testeur était attaqué et que ma clé était prise? Quand je donne la clé de mon appartement à un étranger, je ne peux pas être sûr de sa décence et de ma sécurité.
Heureusement, dans le monde réel, nous avons des documents d’identification, par exemple un permis de conduire ou un passeport, qui sont délivrés par des agences gouvernementales, et leur authenticité ne fait aucun doute. Je peux fournir ces documents au coursier pour ma propre identification sans remettre les clés.
Dans le monde LDAP, nous devons encore passer nos clés pour ouvrir la porte en notre nom. Nous transférons notre mot de passe à un tiers et il essaie de pénétrer le serveur LDAP avec lui. S'il parvient à y accéder, nous ne pouvons pas être sûrs que nos informations d'identification ne sont pas compromises. Dans ce cas, l'attaquant aura non seulement la possibilité de déverrouiller la porte LDAP, mais également d'accéder à n'importe quelle application qui utilise les mêmes informations d'identification.
Heureusement, dans un monde d'authentification plus complet, nous avons aussi des passeports et des permis de conduire! Les protocoles d'authentification tels que Kerberos, SAML et OpenID Connect émettent des jetons à des tiers. Les jetons confirment que vous êtes bien ce que vous prétendez être, et il n'est pas nécessaire de transférer vos clés à quiconque. Parce que LDAP n'a jamais été conçu comme un protocole d'authentification, il manque les mécanismes appropriés.
Inconvénients de LDAP en tant que système d'authentification
En 2007, Shumon Hack a publié un article de science-fiction (
LDAP Weaknesses as a Central Authentication System ) dans lequel il décrit trois problèmes spécifiques lors de l'utilisation de LDAP comme système d'authentification.
1. L'application n'est probablement pas suffisamment sécurisée pour gérer les informations d'identification
L'auteur souligne que la protection d'un petit ensemble de serveurs d'authentification contre les attaques est beaucoup plus facile que la protection d'un grand nombre de serveurs d'applications.
Pour la plupart, les serveurs d'authentification sont, en règle générale, sous la supervision étroite de spécialistes ayant une expérience significative dans le domaine de la sécurité de l'information.
D'un autre côté, les serveurs d'applications ont un niveau de sécurité complètement différent et sont plus à risque de compromis. Ils sont moins sécurisés, fonctionnent avec des piles de logiciels plus complexes et sont plus susceptibles de présenter des vulnérabilités. Et le plus souvent, ils sont gérés par des personnes qui n'ont pas une connaissance approfondie de la sécurité. Construire le bon système de sécurité est un processus compliqué dans lequel il est très facile de se tromper.
Le problème est que si un serveur d'applications est compromis, toutes les informations d'identification utilisées par leurs propriétaires pendant l'attaque sont également compromises. Tout autre système qui utilise le même annuaire LDAP pour l'authentification est en danger.
2. Le serveur LDAP ne peut pas sécuriser le mécanisme d'authentification utilisé pour obtenir les informations d'identification
Un serveur LDAP ne peut garantir la sécurité des transactions. Bien qu'un serveur LDAP, par exemple, puisse appliquer la liaison sur TLS pour garantir que les informations d'identification ne sont pas transmises en texte clair, le serveur lui-même n'a jamais joué de rôle dans l'obtention des informations d'identification de l'utilisateur. Il existe un risque que l'application reçoive un mot de passe via un canal non sécurisé.
3. L'utilisateur est obligé de partager son secret d'authentification avec un tiers
Le mot de passe utilisateur ou le secret d'authentification doit rester
secret . Il ne doit être connu que de l'utilisateur et du système d'authentification. Lors de l'utilisation de l'authentification LDAP, l'utilisateur est obligé de partager son secret avec un tiers afin qu'elle puisse ensuite utiliser ce secret pour interagir avec l'annuaire LDAP au nom de l'utilisateur.
Il est important de mentionner que lors de l'utilisation de protocoles d'authentification spécialement conçus tels que Kerberos, et même à partir du NTLM précédent, le secret de l'utilisateur n'est jamais transmis sur le réseau. Le dispositif client et le serveur utilisent des opérations cryptographiques pour se prouver qu'ils ont le même secret et n'échangent même pas le secret lui-même.
Aux points de Shumon Hook, j'ajouterai une description de plusieurs nuances de l'authentification LDAP, basée sur ma propre expérience. Tout d'abord, le sujet concerne l'utilisation d'Active Directory.
4. De nombreux développeurs ne connaissent pas suffisamment les mécanismes LDAP pour l'utiliser correctement
Un de mes précédents articles de
blog décrit comment la liaison anonyme et non authentifiée a permis de déjouer les développeurs d'applications et a fait sauter les utilisateurs non autorisés. La possibilité d'effectuer une opération de liaison sans authentification est l'une des subtilités du protocole que même les experts LDAP les plus expérimentés ne connaissent pas.
Les répertoires ne sont pas faciles à organiser et capables de stocker une énorme quantité d'informations organisationnelles et offrent de nombreuses façons personnalisables de les stocker. J'ai vu beaucoup de cas où le développeur de l'application supposait qu'il y avait une certaine classe ou attribut d'objet, et quand ils n'étaient pas détectés, l'application se bloquait. Pour l'authentification des utilisateurs, la connaissance de la structure des données stockées dans l'annuaire ne doit pas être requise et appliquée. Le protocole d'authentification doit être extrait des détails du référentiel d'objets situé à un niveau inférieur.
5. Les administrateurs d'applications ne configurent souvent pas correctement les clients LDAP
Lors de la gestion d'Active Directory dans un grand environnement distribué, il existe une nuance désagréable: il est difficile de déterminer quelles applications spécifiques utilisent Active Directory en tant qu'annuaire LDAP et comment les administrateurs d'applications ont configuré le client LDAP exactement.
Ce qui suit sont des exemples des horreurs d'une mauvaise configuration.
- DN de codage en dur dans les applications ou utilisation de DN dans une opération de liaison. Des problèmes surviennent constamment lorsque vous renommez ou déplacez des objets dans un répertoire, et tout cela parce que quelqu'un quelque part DN DN codé en dur. (Remarque pour ceux qui effectuent des opérations de liaison simples avec Active Directory: il n'est pas nécessaire d'utiliser un DN. Active Directory fournit également des formats de DN alternatifs qui sont plus fiables que l'utilisation d'un format traditionnel).
- Pour l'opération de liaison, ce n'est pas un compte de service qui est utilisé, mais un compte personnel du développeur ou de l'administrateur (imaginez ce qui se passera lorsque le propriétaire du compte quittera l'entreprise).
- Envoi de mots de passe en texte clair au port 389.
- Dans certaines applications, la case à cocher «Valider le certificat» n'est pas requise lors de la connexion à AD à l'aide de TLS (port 636). Pourquoi est-ce généralement acceptable? Comment transmettre le mot de passe à un service tiers sans être convaincu de son authenticité?
Faire fonctionner le client LDAP est facile. Mais le simple fait que cela fonctionne ne signifie pas que la configuration est correcte.
6. L'authentification LDAP et les services d'authentification modernes s'excluent mutuellement
Une application qui utilise LDAP pour l'authentification devra toujours s'appuyer sur les noms d'utilisateur et les mots de passe. Essayer d'implémenter des technologies modernes, telles que l'authentification multifacteur et l'authentification unique, est pratiquement impossible (sauf si vous allez implémenter vos propres technologies, ce qui en soi est une mauvaise idée). La FIDO Alliance s'engage à faire des mots de passe une relique du passé et chaque application qui utilise l'authentification LDAP sera un obstacle à une politique sans mot de passe.
Quelles sont les options?
Aujourd'hui, les applications Web peuvent vraiment se passer de l'authentification LDAP. Il existe de nombreux excellents protocoles d'authentification Web, tels que SAML, WS-Federation et OpenID Connect, qui ne nécessitent pas d'informations d'identification utilisateur pour fonctionner avec des applications tierces. D'innombrables produits fournissent ces services, y compris le service de fédération Active Directory (intégré à Windows Server) ou des services tiers tels que Microsoft Azure AD, Okta, Ping et autres. Si votre organisation ne dispose pas d'un IdP fédéré, la première chose à faire est de l'implémenter.
La principale chose à laquelle vous devez faire attention lors du choix d'un nouveau logiciel est la prise en charge des protocoles d'authentification modernes. Même si l'entreprise a besoin de l'application ici et maintenant, ne vous précipitez pas pour choisir une solution, surtout si ce choix se limite uniquement aux produits avec authentification LDAP. Il convient d'essayer de faire comprendre au fournisseur sélectionné la nécessité d'affiner le produit à l'aide de protocoles d'authentification plus modernes. Peut-être qu'il écoutera et révisera son plan de développement.
Le nombre d'applications de bureau avec un "client lourd" qui prend en charge les protocoles d'authentification modernes augmente, et c'est en effet une tendance joyeuse. Ces applications étaient généralement un bastion de l'authentification LDAP. Un nombre croissant de SDK, tels que la bibliothèque d'authentification Microsoft (MSAL), permettent aux développeurs d'ajouter facilement la prise en charge des services d'authentification modernes à leurs applications mobiles et de bureau.
En fin de compte, il convient de reconnaître que dans la réalité d'aujourd'hui, toutes les applications ne prennent pas en charge les protocoles d'authentification modernes, et ne le seront peut-être jamais. La mise en œuvre d'une interdiction complète de l'authentification LDAP n'est probablement pas possible dans aucune organisation. Cependant, l'authentification LDAP ne doit en aucun cas être encouragée au sein de l'organisation. L'utilisation de LDAP ne doit être envisagée qu'en l'absence d'autres options.