Qu’est-ce que l’authentification défaillante ? Exemples et comment la prévenir

Qu’est-ce que l’authentification défaillante ? Qu’est-ce qu’un mot de passe fort ? Comment une mauvaise gestion de session peut-elle conduire à une authentification compromise ? Lisez cet article pour le découvrir.

Les incidents de violation de données sont en hausse depuis quelques années. Selon le rapport IBM 2022, le coût mondial d’une violation de données a atteint 4,35 millions de dollars, les États-Unis occupant la première place avec un coût moyen de violation avoisinant 9,5 millions de dollars. Les hackers continuent d’utiliser des méthodes éprouvées tout en inventant de nouvelles techniques pour obtenir des données sensibles sur les consommateurs.

L’une des façons d’infiltrer un système ciblé consiste à exploiter différentes vulnérabilités d’authentification. L’authentification défaillante dépend souvent d’autres attaques telles que l’ingénierie sociale, le phishing, l’attaque de l’homme du milieu ou le cross-site scripting.

Dans cet article, nous expliquerons quels comportements utilisateurs et quelles erreurs de développement conduisent à une authentification défaillante, et nous partagerons des stratégies efficaces pour la prévenir.

Qu’est-ce que l’authentification défaillante ?

Avant d’aborder l’authentification défaillante, commençons par définir l’authentification. En substance, l’authentification consiste à vérifier l’identité d’un utilisateur en lui demandant des informations privées connues de lui seul, telles que son identifiant, son adresse e-mail et son mot de passe, ou un scan d’empreinte digitale.

L’authentification défaillante est une vulnérabilité web qui permet aux hackers de contourner les contrôles d’authentification, de voler l’identité d’une personne pour se connecter, ou de compromettre d’autres mécanismes de sécurité. L’authentification défaillante peut être causée à la fois par une gestion négligente des identifiants et par une mauvaise gestion de session.

Exemples de mauvaise gestion des identifiants

L’utilisation des identifiants d’une autre personne est l’un des moyens les plus courants pour les acteurs malveillants d’accéder à un système. En 2022, les identifiants volés constituaient le principal vecteur d’attaque dans 19 % des violations selon l’étude IBM 2022. Ce n’est pas surprenant.

Tout d’abord, de nombreuses personnes utilisent des mots de passe faibles — et nous ne parlons pas seulement du « 123 », de « admin », des noms d’animaux de compagnie ou des dates de naissance, bien que des millions d’utilisateurs continuent de les utiliser. Les données ci-dessous parlent d’elles-mêmes.

De plus, des recherches montrent que 44 % des consommateurs changent leur mot de passe très rarement. Cela signifie que les hackers peuvent lancer des attaques par force brute et des attaques par pulvérisation de mots de passe pour voler des identifiants avec peu d’efforts.

Les attaques par force brute sont automatisées et reposent sur une simple méthode d’essai-erreur. La pulvérisation de mots de passe est un type d’attaque par force brute. Cependant, au lieu d’essayer de nombreux mots de passe sur un seul compte, elle utilise le même mot de passe pour plusieurs utilisateurs. Cette technique permet aux hackers de contourner les verrouillages de compte après un certain nombre de tentatives de connexion échouées.

Un autre groupe de personnes utilise le même e-mail et le même mot de passe sur tous leurs comptes. Selon Statista, seuls 12 % des utilisateurs créaient systématiquement de nouveaux mots de passe lors de l’inscription à de nouveaux comptes en 2021, tandis que 45 % réutilisaient toujours ou souvent leurs anciens mots de passe.

Cela a donné naissance aux attaques par credential stuffing. Le darknet regorge d’adresses e-mail et de mots de passe divulgués provenant de différentes organisations. Parce que les gens utilisent les mêmes mots de passe pour plusieurs applications, les attaquants peuvent utiliser les identifiants obtenus sur le darknet et les essayer sur des sites ciblés. Le credential stuffing est également une attaque automatisée, ce qui en fait une démarche peu coûteuse en effort pour les hackers.

Mais les utilisateurs ne sont pas les seuls responsables ; des erreurs peuvent également être commises du côté des développeurs. Par exemple, les mots de passe peuvent être stockés en texte clair ou utiliser des hachages faibles, ce qui permet aux hackers de les déchiffrer facilement avec des tables arc-en-ciel.

Pourquoi la gestion de session est-elle importante ?

La gestion de session est une partie intégrante des applications web modernes. Une session web est une séquence de requêtes et de réponses HTTP réseau relatives au même utilisateur. Les applications web utilisent les sessions pour conserver des informations sur un utilisateur particulier afin de répondre correctement à toutes ses actions et demandes pendant la durée de la session.

Par exemple, lorsqu’un utilisateur navigue sur le site pour la première fois, ses préférences linguistiques seront sauvegardées tout au long de la session, ce qui améliore la convivialité.

Les sessions sont également utiles dans les scénarios post-authentification. Une fois que l’utilisateur s’est authentifié, l’application web pourra l’identifier lors des interactions ultérieures et appliquer les contrôles de sécurité appropriés.

Une fois une session créée, l’utilisateur se voit attribuer un identifiant ou jeton de session temporairement équivalent à la méthode d’authentification la plus robuste, qui est échangé entre l’utilisateur et l’application web pendant la session.

Exemples d’authentification et de gestion de session défaillantes

Une implémentation correcte des sessions joue un rôle considérable dans la prévention des vulnérabilités d’authentification. Voici quelques exemples illustrant comment une mauvaise gestion de session conduit à une authentification défaillante.

Détournement de session. Il peut prendre de nombreuses formes. L’exemple le plus simple de détournement de session est lorsqu’un utilisateur oublie d’invalider sa session sur un ordinateur public : il peut fermer les fenêtres du navigateur sans se déconnecter des applications. Dans ce cas, la personne qui utilise ensuite le même ordinateur pourrait facilement usurper l’identité de cet utilisateur, car la session est toujours active et les applications déverrouillées.

Mais les hackers ne se contentent pas de se rendre dans des lieux publics pour tenter leur chance. La plupart de leurs attaques sont planifiées à l’avance et effectuées à distance. Une autre façon de détourner une session consiste à intercepter le trafic réseau à l’aide d’analyseurs de paquets comme Wireshark. Si les applications web utilisent le chiffrement TLS uniquement sur les pages de connexion, les hackers peuvent surveiller le trafic sur les autres pages et voler les cookies de session.

Les acteurs malveillants peuvent également tenter de voler le jeton de session via le cross-site scripting (XSS). Ils créent essentiellement un lien contenant un code spécial qui s’exécutera une fois cliqué. Le script peut être écrit en JavaScript ou dans tout autre langage côté client. Voici un exemple de script malveillant qui révélera la valeur du cookie dans une fenêtre contextuelle :

<script>

    alert(document.cookie);

</script>

Fixation de session. Dans une attaque de fixation de session, le hacker se connecte à l’application web pour obtenir un identifiant de session valide, puis incite un utilisateur légitime — que ce soit par ingénierie sociale ou via un site de phishing — à s’authentifier avec cet identifiant de session. Ainsi, si l’application ne renouvelle pas l’identifiant de session lors de l’authentification, le hacker peut usurper l’identité de l’utilisateur et accéder à son compte.

Voici un exemple de lien malveillant qui modifiera la valeur de l’identifiant de session de la victime dans son cookie si elle clique dessus :

http://website.сom/<script>document.cookie=”sessionid=abcd”;</script>

Réécriture de l’URL avec l’identifiant de session. Si une application web insère l’identifiant de session dans l’URL au lieu de le stocker dans le cookie, elle l’expose et permet à toute personne suivant l’URL d’hériter de la session. Ainsi, si une telle URL est partagée par erreur, un autre utilisateur peut prendre le contrôle de la session sans avoir besoin de s’authentifier.

Entreprises touchées par l’authentification défaillante

Examinons des exemples concrets d’entreprises qui ont subi des violations de données en raison d’une mauvaise gestion des identifiants ou d’autres vulnérabilités d’authentification.

Revolut est une application financière permettant d’envoyer des fonds, de demander des paiements et de partager des factures dans plus de 200 pays. En septembre 2022, Revolut a subi une violation de données, exposant les noms, e-mails, numéros de téléphone, adresses postales, détails des appareils, historiques de transactions et dernières adresses IP connues d’environ 50 000 utilisateurs.

Bien que les données de débit et de crédit aient été masquées et inutilisables, les informations volées peuvent être utilisées pour du vol d’identité et des attaques de phishing. Les enquêteurs estiment que la base de données a été compromise par un employé victime d’une attaque d’ingénierie sociale minutieusement élaborée, qui a transmis ses identifiants de connexion aux hackers.

Twilio est une plateforme d’engagement client proposant des API de communication pour les canaux SMS, voix et vidéo. Twilio a été victime d’une violation en août 2022 ; des hackers ont accédé aux données de 125 clients de Twilio. Parmi les victimes indirectes de la violation figuraient de grands noms comme Signal et Okta. L’attaque a été menée en incitant des employés à suivre une URL de phishing reçue par SMS, prétendument pour mettre à jour des mots de passe expirés ou consulter des changements de planning.

Twitter, l’un des plus grands réseaux sociaux au monde, a également été piraté en 2022. Une mise à jour du code en juin 2021 avait provoqué la vulnérabilité suivante : lorsque des hackers soumettaient un e-mail ou un numéro de téléphone au système de Twitter, le site révélait le compte Twitter associé à ce numéro ou à cet e-mail. En conséquence, les données personnelles de 200 millions d’utilisateurs ont été divulguées, ce qui pourrait conduire à des fraudes de phishing ou à du vol d’identité à l’avenir.

Crypto.com est une plateforme d’échange de cryptomonnaies qui a perdu environ 30 millions de dollars en Bitcoin et en Ethereum. Son système d’authentification à deux facteurs s’est avéré suffisamment faible pour être contourné par des hackers. Ces derniers ont réussi à retirer des fonds de 483 comptes clients. L’entreprise a l’intention de remplacer l’authentification à deux facteurs par une authentification multifacteur pour prévenir de tels incidents à l’avenir.

LastPass est un gestionnaire de mots de passe permettant de stocker et de partager des mots de passe et d’autres documents importants. Il a été victime de deux violations. La première fois, des hackers ont volé une partie du code source et certaines informations techniques propriétaires via le compte compromis d’un développeur. La deuxième fois, ils ont volé les coffres de mots de passe des clients. Bien que ces derniers soient chiffrés, les hackers peuvent tenter de craquer les mots de passe maîtres qui verrouillent les coffres par force brute.

Comment prévenir l’authentification défaillante

La meilleure façon de prévenir l’authentification défaillante est de mettre en place une approche de sécurité à plusieurs couches. Passons en revue les éléments essentiels qui vous aideront à y parvenir.

Ajouter l’authentification multifacteur

L’authentification multifacteur (MFA) est une couche de sécurité supplémentaire qui oblige l’utilisateur à fournir une preuve d’identité supplémentaire pour se connecter. Il peut s’agir d’un code PIN, d’un code envoyé sur votre téléphone ou par e-mail, d’une empreinte digitale, d’un scan du visage ou de l’iris, ou d’un mot de passe à usage unique basé sur le temps (TOTP) provenant d’une application d’authentification dédiée.

Microsoft estime que l’ajout du MFA aurait bloqué 99,9 % des attaques automatisées liées aux mots de passe. Cependant, le MFA présente plusieurs inconvénients : il réduit la convivialité, introduit des dépendances externes dans le système et ne propose pas de moyen simple de le réinitialiser sans compromettre son efficacité.

Pour y remédier, le MFA peut être mis en œuvre uniquement pour les administrateurs et les utilisateurs disposant de droits à hauts privilèges, ou uniquement pour les transactions à fort impact. La forme sous laquelle le MFA doit être implémenté dépend de facteurs tels que le modèle de menace de l’application, la maîtrise technologique des utilisateurs, le degré de contrôle administratif sur les utilisateurs et les coûts associés.

Ajouter un CAPTCHA

Le CAPTCHA est l’acronyme de « Completely Automated Public Turing Test to Tell Computers and Humans Apart » (test de Turing public entièrement automatisé permettant de distinguer les ordinateurs des humains). En termes simples, c’est une vérification rapide pour distinguer les humains des robots.

Les CAPTCHAs originaux exigeaient que l’utilisateur déchiffre des caractères et des chiffres déformés et superposés, puis les saisisse dans un champ de texte. Les robots étant de plus en plus capables de reconnaître des motifs, des tests plus complexes basés sur des images sont apparus.

Les CAPTCHAs ajoutent inévitablement de la friction au parcours utilisateur, il est donc judicieux de les utiliser uniquement après quelques tentatives de connexion échouées.

Bien que le CAPTCHA rende les attaques par force brute plus contraignantes et plus coûteuses, il ne peut pas garantir une protection à 100 % contre celles-ci.

Stocker les mots de passe de manière sécurisée

Il est désormais bien connu que les mots de passe ne doivent jamais être stockés en texte clair, car les bases de données sont régulièrement compromises. Ainsi, même si un hacker met la main sur la base de données, son contenu restera encodé.

Les développeurs peuvent y parvenir grâce à des algorithmes de hachage modernes. Le hachage, contrairement au chiffrement, est une fonction à sens unique : il est impossible de le déchiffrer, c’est pourquoi les mots de passe doivent être hachés plutôt que chiffrés.

Il existe néanmoins des contournements, comme le calcul des hachages de mots de passe couramment utilisés, puis leur comparaison avec les hachages issus de la base de données compromise. Pour compliquer la tâche des hackers, les hachages de mots de passe doivent être salés, c’est-à-dire qu’une chaîne générée aléatoirement et unique pour chaque utilisateur sera ajoutée aux hachages.

Les hachages de mots de passe salés prennent nettement plus de temps à craquer et rendent impossible de déterminer si deux utilisateurs ont le même mot de passe, car des sels différents produisent des hachages différents, que les mots de passe des utilisateurs soient identiques ou non.

Imposer des politiques de mots de passe forts

Qu’est-ce qu’un mot de passe fort ? Selon le National Institute of Standards and Technology, les mots de passe doivent comporter au moins 8 caractères et ne pas contenir de caractères répétitifs ou séquentiels (comme « aaaa » ou « abc123 »). De plus, les utilisateurs doivent pouvoir choisir parmi tous les caractères, y compris Unicode et les espaces.

Mais il s’agit du seuil minimal, et vous ne souhaitez pas être au bas de l’échelle en matière de sécurité. Le Standard de vérification de la sécurité des applications OWASP exige des mots de passe d’au moins 12 caractères, tandis que les développeurs de gestionnaires de mots de passe comme Bitwarden recommandent 14 à 16 caractères.

En général, plus le mot de passe est long, mieux c’est, car cela augmente le nombre de combinaisons qu’un botnet doit tester pour le craquer. Gardez toutefois à l’esprit que les caractères doivent être générés aléatoirement.

Certains sites web limitent le nombre de caractères utilisables. Une autre façon d’ajouter de la complexité à votre mot de passe est d’utiliser des majuscules, des caractères spéciaux et des chiffres. Là encore, le caractère aléatoire est un facteur clé. Par exemple, « Logmein!321 » est un très mauvais modèle de mot de passe, tandis que « l_w4XgH9~Wiq » est ce que nous cherchons à atteindre.

Le formulaire de connexion doit intégrer un indicateur de force de mot de passe, vérifiant les mots de passe par rapport aux mots du dictionnaire, aux mots de passe précédemment compromis, ou aux mots spécifiques au contexte comme le nom du service ou de l’utilisateur et leurs dérivés.

Lors de la mise en place de politiques d’expiration des mots de passe, gardez à l’esprit que les employés ont tendance à ne modifier qu’un seul caractère pour s’en débarrasser et reprendre leurs tâches quotidiennes. Il est donc important de sensibiliser les employés à ce qui constitue un mot de passe fort et de ne demander le changement de mot de passe qu’en cas de suspicion ou de compromission avérée. Car les hackers n’attendent pas lorsqu’ils disposent d’identifiants exposés, ils agissent immédiatement.

Créer des mots de passe forts pour de nombreux services et les stocker de manière sécurisée représente certainement un fardeau supplémentaire pour les employés. Les organisations doivent donc fournir une méthode approuvée pour générer et stocker les mots de passe d’entreprise, qu’il s’agisse d’un support physique, d’un logiciel de gestion des mots de passe, ou d’une combinaison des deux, et définir clairement les comportements attendus des employés dans différents scénarios.

Sinon, les employés continueront à utiliser des mots de passe faibles et faciles à mémoriser, improvisant avec le stockage en sauvegardant les mots de passe sur leurs téléphones personnels ou dans des brouillons Gmail.

Pour prévenir les attaques par déni de service liées à des mots de passe trop longs, la longueur maximale des mots de passe doit être définie, généralement à 64 caractères.

Améliorer le seuil de verrouillage des comptes

Le verrouillage de compte est une arme à double tranchant. D’un côté, c’est l’une des protections les plus courantes et les plus efficaces contre les attaques par force brute, car le compte sera simplement verrouillé après un certain nombre de tentatives échouées.

De l’autre, les verrouillages de compte peuvent facilement créer une situation de déni de service. Les hackers peuvent lancer des attaques automatisées contre tous les utilisateurs d’une organisation, provoquant des verrouillages massifs de comptes et inondant les équipes d’assistance client d’appels. Le coût des interruptions de service et les risques pour la réputation seraient considérables.

Un autre scénario est celui d’un utilisateur pressé ou agité qui saisit mal son e-mail ou son mot de passe à plusieurs reprises. Si le seuil de verrouillage est trop bas, cela peut déclencher un verrouillage accidentel.

Malheureusement, il n’existe pas de solution miracle pour résoudre le dilemme du verrouillage de compte. Il appartient à chaque entreprise de trouver le juste équilibre entre sécurité et efficacité opérationnelle. Lors de la définition du seuil de verrouillage, il est important de calculer le nombre de tentatives dont disposent les attaquants par jour et de les ralentir en ajustant le seuil de verrouillage, la durée et les paramètres de réinitialisation en conséquence.

Afficher des erreurs génériques

La gestion des erreurs est une autre faille permettant aux acteurs malveillants de recueillir des informations et d’infiltrer un système. Des messages d’erreur trop précis facilitent considérablement la tâche des hackers, car ils savent exactement ce qui s’est passé, quelles technologies et versions de framework sont utilisées, et peuvent planifier leur attaque en conséquence.

Par exemple, lorsqu’un acteur malveillant tente de se connecter avec les identifiants d’une autre personne et voit « Connexion échouée ; compte désactivé », il ne perd pas son temps et passe à un autre compte. Pire encore, le nom de l’utilisateur peut être révélé dans le message lui-même, comme « Connexion pour l’utilisateur Boo : mot de passe invalide ».

C’est pourquoi il est préférable d’afficher des messages d’erreur génériques pour l’inscription, la connexion d’un utilisateur existant et la récupération de mot de passe.

Un autre aspect à considérer est le temps de traitement. Il doit être identique quel que soit le résultat, afin que le hacker ne puisse pas effectuer une attaque temporelle.

Par exemple, avec l’approche « sortie rapide », l’application génère rapidement une erreur si l’utilisateur n’existe pas. En revanche, si l’utilisateur existe mais que le mot de passe est incorrect, l’application effectue davantage d’étapes et met plus longtemps à répondre. Cela permet au hacker de différencier un nom d’utilisateur incorrect d’un mot de passe incorrect en se basant sur le temps de réponse aux erreurs.

Il est également crucial de s’assurer qu’aucune information ne soit divulguée via l’URL. L’application peut renvoyer un message générique à l’utilisateur, mais utiliser un code d’erreur HTTP différent selon que la connexion est réussie (200 OK) ou échouée (403 Forbidden).

Bien que les messages génériques compliquent la reconnaissance pour les hackers, ils peuvent dérouter les utilisateurs et nuire à l’adoption de l’application et à la fidélisation. Trouver un équilibre entre convivialité et sécurité est donc quelque chose que chaque entreprise doit définir par elle-même.

Abandonner les questions de sécurité

Les questions de sécurité ne sont plus considérées comme un mécanisme d’authentification acceptable. Il convient également de noter que l’utilisation d’un mot de passe combiné à une question de sécurité n’est pas équivalente au MFA, car le facteur est le même dans les deux cas : quelque chose que vous connaissez.

Il existe deux types de questions de sécurité — définies par l’utilisateur et définies par le système — et les deux sont faciles à compromettre. Examinons les questions de sécurité définies par l’utilisateur les plus courantes et leurs faiblesses :

Bien sûr, vous pouvez inventer des questions plus complexes comme « Quel est le nom d’une université à laquelle vous avez postulé mais que vous n’avez pas fréquentée ? » ou « Quel est le nom de famille de votre professeur de mathématiques en 5ème ? » Mais êtes-vous sûr que tous les utilisateurs s’en souviendront ? Une solution consiste à proposer une liste de questions parmi lesquelles choisir, mais il n’y a toujours aucune garantie que les réponses ne seront pas devinées.

Dès 2015, une étude de Google a confirmé que les questions de sécurité sont soit sûres, soit faciles à mémoriser, mais jamais les deux. Alors que 40 % des utilisateurs ne se souvenaient pas des réponses à leur question de sécurité, 37 % fournissaient délibérément de fausses réponses pour les rendre plus difficiles à deviner, obtenant l’effet inverse.

Quant aux questions définies par le système, elles reposent sur des informations déjà enregistrées dans le système, comme le nom de l’utilisateur, sa date de naissance ou son adresse. Ces informations peuvent cependant aussi être découvertes via les réseaux sociaux ou les fuites du dark web.

Mettre à jour vos frameworks

La mise en œuvre d’un module de gestion de session sécurisé est assez complexe, car elle combine l’authentification, le trafic HTTP des utilisateurs et les contrôles d’accès appliqués par l’application web. C’est pourquoi il est recommandé d’utiliser les fonctionnalités de gestion de session intégrées et les guides d’implémentation proposés par des frameworks bien connus plutôt que de les coder soi-même.

En même temps, même les frameworks largement adoptés et bien testés peuvent contenir des vulnérabilités. Assurez-vous donc d’utiliser les versions les plus récentes des frameworks, qui intègrent les correctifs pour les vulnérabilités connues. De plus, modifiez la configuration par défaut pour renforcer la sécurité de votre application.

Générer un identifiant de session sécurisé

Le nom par défaut de l’identifiant de session peut révéler les technologies et langages de programmation utilisés par l’application web. Par exemple, PHPSESSID indique PHP, JSESSIONID est généré par J2EE, tandis que CFID et CFTOKEN suggèrent que l’application est construite avec ColdFusion. C’est pourquoi le nom par défaut doit être remplacé par quelque chose de générique et peu descriptif.

La longueur de l’identifiant de session est importante. Comme les mots de passe, elle doit être suffisamment longue pour prévenir les attaques automatisées ; l’OWASP recommande au moins 128 bits, bien que ce chiffre ne soit pas rigide et que d’autres détails d’implémentation doivent être pris en compte.

L’identifiant de session doit également avoir une entropie efficace. En d’autres termes, il doit être aléatoire et imprévisible pour résister aux techniques d’analyse statistique. Cela peut être réalisé avec un CSPRNG (générateur de nombres pseudo-aléatoires cryptographiquement sécurisé) fiable.

Les objets et propriétés de session, comme l’adresse IP de l’utilisateur, son e-mail, ses droits d’accès ou sa dernière connexion, doivent être stockés sur le serveur dans une base de données ou un référentiel de gestion de session protégé.

Enfin, et ce n’est pas le moins important, l’identifiant de session doit être unique, ce qui signifie qu’une session en cours ne peut pas contenir d’identifiants dupliqués.

Choisir le bon mécanisme d’échange d’identifiant de session

L’application web et l’utilisateur ont besoin d’un mécanisme permettant de partager et d’échanger l’identifiant de session. Il existe plusieurs façons de procéder : via des cookies, des paramètres d’URL, des arguments d’URL dans les requêtes GET, ou des arguments de corps dans les requêtes POST.

Lors du choix d’un mécanisme d’échange d’identifiant de session approprié, vérifiez s’il permet de définir des propriétés avancées du jeton, comme la date et l’heure d’expiration, ainsi que des politiques d’utilisation granulaires. Les cookies HTTP figurent parmi les mécanismes d’échange d’identifiant de session les plus largement utilisés, car ils offrent ces fonctionnalités et bien d’autres.

Les paramètres d’URL, en revanche, sont considérés comme un mécanisme d’échange d’identifiant de session obsolète, car ils peuvent révéler l’identifiant de session dans l’URL et permettre aux hackers d’effectuer des attaques de fixation de session ou d’autres manipulations d’identifiant.

Un autre point à considérer est que même si l’application utilise des cookies par défaut, elle peut encore accepter d’autres mécanismes d’échange ou passer des cookies aux paramètres d’URL dans certaines conditions. Par conséquent, des tests rigoureux sont nécessaires pour définir comment l’application traite et gère les identifiants de session dans différents scénarios et s’assurer qu’elle s’appuie exclusivement sur les cookies.

Mettre en place des contrôles contre l’écoute clandestine

Les identifiants de session peuvent être interceptés ou volés par écoute du trafic réseau. Pour éviter cela, les applications web doivent mettre en place une protection au niveau de la couche de transport.

Le protocole TLS (Transport Layer Security) est l’un des protocoles les plus modernes pour chiffrer les communications entre une application web et un serveur.

Naturellement, les développeurs web doivent utiliser la dernière version de TLS, car elle est plus rapide et moins vulnérable que ses prédécesseurs ; au moment de la rédaction, il s’agit de TLS 1.3.

Le TLS doit être appliqué à toutes les pages, quelle que soit leur sensibilité. Sinon, vous offrez une faille à un acteur malveillant pour espionner les jetons de session ou injecter du code JavaScript malveillant pour mener d’autres attaques. Pour les mêmes raisons, il ne doit pas y avoir de mélange de contenu TLS et non-TLS. Les pages disponibles via TLS ne peuvent contenir aucun fichier JavaScript ou CSS chargé via un HTTP non sécurisé.

Bien que le TLS protège les données en transit, il ne protège pas les données qui ont atteint le système, comme celles stockées dans le cache du navigateur de l’utilisateur.

Renouveler l’identifiant de session après un changement de privilège

Il est essentiel de s’assurer que votre application web n’utilise pas un jeton précédemment attribué lorsque le niveau de privilège de l’utilisateur change. Par exemple, lorsque l’utilisateur passe d’un utilisateur ordinaire à un administrateur ou superutilisateur, l’application doit ignorer les anciens identifiants de session et en générer un nouveau.

L’OWASP recommande également d’attribuer un identifiant de session différent lorsque l’utilisateur passe d’un visiteur anonyme à un utilisateur authentifié. Cela permet d’éliminer le risque de liaison de la session utilisateur entre les deux états. La régénération de l’identifiant de session est essentielle pour prévenir les attaques de fixation de session.

Définir des délais d’expiration de session

Les délais d’expiration de session sont utiles car ils limitent le temps dont dispose un acteur malveillant pour détourner la session. Ainsi, plus la durée de session est courte, mieux c’est. C’est pourquoi les applications très sensibles n’accordent que 2 à 5 minutes avant que l’utilisateur doive se ré-authentifier.

Bien entendu, l’intervalle d’expiration de session dépend de la nature de l’application et des cas d’utilisation réels. Pour un employé de bureau, il faudra 8 heures de session active, à condition que toutes ses tâches impliquent d’interagir avec l’application.

Il existe plusieurs types de délais d’expiration : inactif, absolu et de renouvellement. Les délais d’inactivité sont appliqués lorsqu’il n’y a pas de nouvelle activité après un temps spécifique. Ils visent à réduire le temps dont dispose un hacker pour deviner un identifiant de session valide. À l’inverse, si la session est déjà détournée, l’attaquant peut périodiquement générer une activité pour prolonger la session.

Les délais absolus définissent la durée maximale pendant laquelle une session peut être active, la fermant automatiquement à l’expiration. Lors des délais de renouvellement, un nouvel identifiant de session est généré au milieu de la session en cours, quel que soit l’activité de l’utilisateur, et l’identifiant précédent est invalidé dès que l’utilisateur envoie une nouvelle requête.

Une fois la limite de session atteinte, l’application web doit invalider la session côté client et côté serveur, afin que l’attaquant ne puisse pas manipuler les paramètres client pour suivre le temps, comme le nombre de minutes depuis la connexion.

Détecter et surveiller les anomalies de session

Les applications web doivent disposer de capacités de détection d’anomalies intégrées pour alerter les utilisateurs d’un comportement inhabituel ou mettre fin aux sessions suspectes. Voici les éléments indiquant une possible intrusion :

• différents identifiants de session sont essayés depuis la même adresse IP de manière séquentielle
• un cookie existant est supprimé ou modifié
• un nouveau cookie est ajouté
• l’identifiant de session d’un autre utilisateur est réutilisé
• la localisation de l’utilisateur change au cours d’une session

Les applications web doivent enregistrer les informations de session tout au long de leur cycle de vie, de la création et du renouvellement jusqu’à la destruction de l’identifiant de session. Les événements tels que la connexion et la déconnexion, les tentatives de connexion échouées, les connexions simultanées, les changements de privilège et les transactions à fort impact doivent également être consignés. L’identifiant de session lui-même doit être enregistré sous forme de hachage salé.

En ce qui concerne les fonctionnalités destinées aux clients, les utilisateurs doivent pouvoir consulter les détails des sessions actives, des appareils connectés et des adresses IP. Ils doivent recevoir des notifications concernant les connexions simultanées et avoir la possibilité de mettre fin aux sessions à distance sur tous les appareils.

Passer à l’authentification sans mot de passe

Si les mots de passe posent autant de problèmes, pourquoi les utiliser du tout ? De nombreuses entreprises ont déjà adopté ou envisagent d’adopter l’authentification sans mot de passe. Selon l’enquête Bitwarden 2022, 41 % des 800 décideurs informatiques interrogés estiment que l’authentification sans mot de passe améliore la sécurité, tandis que les autres soulignent son effet sur l’augmentation de la productivité au travail, une meilleure expérience utilisateur et la réduction du recours au service d’assistance.

De plus, si votre application web se connecte à une application tierce, vous ne souhaitez pas que cette dernière stocke les identifiants de connexion des utilisateurs, car cela augmente le risque de violation et vous n’avez aucun contrôle sur la sécurité de l’application tierce. Dans ce cas, l’utilisation de protocoles d’authentification sans mot de passe est la seule option.

Voici quelques-uns des protocoles d’authentification les plus connus ne nécessitant pas de mot de passe.

• OAuth 2.0 — un framework d’autorisation open source qui permet à une application tierce d’obtenir un accès limité à un service HTTP. Au lieu de s’appuyer sur les identifiants de l’utilisateur, l’application tierce reçoit un jeton d’accès spécial. OAuth 2.0 est utilisé par de grands noms comme Meta, Google, Twitter et Microsoft.

• OpenID — une technologie open source décentralisée qui permet d’utiliser un seul compte pour accéder à plusieurs sites web. Vous partagez vos identifiants avec un seul fournisseur d’identité de confiance, puis vous vous connectez via ce fournisseur sans révéler vos véritables identifiants. Plus de 50 000 sites web acceptent OpenID pour les connexions.

• SAML — Security Assertion Markup Language. Comme OpenID, SAML permet d’accéder à plusieurs applications web avec un seul jeu d’identifiants de connexion. La différence réside dans le fait qu’il est basé sur XML, offre plus de flexibilité et est mieux adapté aux environnements d’entreprise.

• FIDO — acronyme de Fast Identity Online. Les protocoles FIDO reposent sur des techniques de cryptographie à clé publique. Lors de l’inscription sur un site web, l’appareil de l’utilisateur génère une paire de clés, conservant la clé privée et enregistrant la clé publique auprès du service en ligne. Pour s’authentifier, l’utilisateur doit prouver la possession de la clé privée en la déverrouillant localement sur son appareil en saisissant un code PIN, en parlant dans un microphone, en insérant un appareil de second facteur, en glissant un doigt, etc.

Investir dans les tests d’intrusion

Les tests d’intrusion sont un type de tests qui simulent l’attaque d’un hacker dans un environnement contrôlé. Les testeurs d’intrusion utilisent une combinaison d’outils de sécurité comme les scanners de vulnérabilités et des techniques manuelles employées par de véritables attaquants. Cela fait des tests d’intrusion un élément fondamental pour améliorer la posture de sécurité d’une entreprise.

Les tests d’intrusion sont une composante indispensable des réglementations de conformité telles que HIPAA, SOC 2 ou PCI-DSS, ce qui confirme leur efficacité pour découvrir les failles de sécurité et les combler en temps opportun.

Chez QAwerk, nous aidons les startups et les entreprises établies à tester en profondeur leurs modules d’authentification, à identifier les menaces potentielles et à trouver des moyens efficaces de corriger ces vulnérabilités. Notre liste de contrôle des tests d’intrusion inclut tous les points mentionnés et bien d’autres, en fonction des spécificités techniques de votre produit.

En plus d’une analyse dynamique de votre application, nous pouvons également examiner le code source avant une version majeure ou le lancement d’un nouveau produit, afin que vous puissiez offrir de nouvelles fonctionnalités aux consommateurs en toute sérénité. Si vous souhaitez en savoir plus sur la façon dont nous pouvons vous aider à rendre votre logiciel résistant aux hackers et sur notre processus de tests d’intrusion, n’hésitez pas à nous contacter par e-mail. Nous proposons des consultations gratuites et sans engagement pour voir si nous sommes la bonne solution pour vos besoins.

En résumé

L’authentification défaillante figure parmi les dix principales vulnérabilités web classées par l’OWASP. Bien que les défaillances d’identification et d’authentification aient diminué ces dernières années grâce aux frameworks standardisés, elles représentent toujours un risque considérable et sont exploitées quotidiennement par des acteurs malveillants.

Aligner votre application sur les meilleures pratiques de sécurité en matière de gestion des identifiants et de gestion de session, sensibiliser les employés à l’ingénierie sociale et à l’hygiène numérique, et effectuer des audits de sécurité réguliers par une entité qualifiée vous protégera des violations de données et de leurs conséquences.

Renforcez dès maintenant la sécurité de votre application web : l’aide-mémoire ultime sur l’authentification défaillante

Veuillez saisir votre adresse courriel professionnelle n'est pas un courriel professionnel

Obtenir le PDF