J3.x

J3.x : Modifications des recommandations de la génération de jetons 2FA pour les sites existants

From Joomla! Documentation

This page is a translated version of the page J3.x:Changes to the 2FA token generation recommendations for existing sites and the translation is 100% complete.

Other languages:
Deutsch • ‎English • ‎español • ‎français • ‎italiano • ‎中文(繁體)‎ • ‎中文(台灣)‎

Cette page comprend des détails sur les correctifs de sécurité publiés avec Joomla 3.9.25 concernant la configuration 2FA. Vous trouverez ici une analyse d'impact ainsi que des recommandations pour les sites existants.

Erreurs signalées

L'équipe JSST a été contacté par le chercheur en sécurité Hanno Böck et a été informé de deux problèmes dans le code qui ont été corrigés par cette mise à jour.

Versions affectées

Informations générales

Ceci ne concerne que les versions Joomla!: 3.2.0 - 3.9.24

Quelle en est la cause ?

À partir de la version 3.2.0 de Joomla, le noyau de Joomla est livré avec le support de base de 2FA / TOTP. Jusqu'à la version 3.9.25, l'implémentation présentait deux failles de sécurité mineures :

  • Utilisation de la fonction rand() non sécurisée dans le processus de génération du secret 2FA.
  • Utilisation d'une longueur insuffisante pour le secret 2FA selon la RFC 4226 de 10 octets contre 20 octets.

Comment le problème a été résolu

À partir de la version 3.9.25 de Joomla, la mise en œuvre du noyau de Joomla a été mise à jour :

  • Utilisation d'une fonction aléatoire sécurisée (random_int ; rétroportage dans les anciennes versions de PHP par la bibliothèque paragonie/random_compat).
  • Utiliser 20 octets contre l'ancienne valeur de 10 octets pour générer le secret 2FA.

Ce problème a été coordonné avec Akeeba Ltd en tant que contributeur de la base de code originale de FOF au noyau.

Est-ce que cela affecte mon site web

Comme indiqué dans le rapport initial fourni par Hanno Böck, il a déclaré à propos de l'utilisation de la fonction rand non sécurisée :

[...] Je considère que le risque pratique de ceci est faible. Pour attaquer cela, un attaquant devrait connaître l'heure approximative à laquelle la personne a créé son secret TOTP. PHP mélange en interne deux fois les microsecondes, donc on pourrait peut-être réduire les options possibles pour la clé à quelques millions, ce qui reste très peu pratique pour une attaque réelle. [...]


Et pour l'utilisation de 10 contre 20 octets, il a dit ce qui suit :

[...] Le code par défaut utilise 10 octets pour le secret. 10 octets, c'est 80 bits. Le risque ici est faible. 80 bits sont encore en dehors de toute attaque pratique. Néanmoins, je pense que les exigences de sécurité (et même les recommandations) de la RFC devraient être suivies, donc je recommande de changer cela en 20 octets (aka 160 bits). [...]


Sur la base de ces informations, l'équipe JSST a décidé de mettre en œuvre les changements mentionnés ci-dessus, mais cela ne signifie pas explicitement que pratiquement tous les tokens 2FA générés avant le patch doivent être régénérés, car ils fonctionnent toujours comme prévu et sont toujours sécurisés d'un point de vue pratique. Il devrait également être évident que les changements effectués ici n'affectent que les secrets générés après ce changement.