J3.x:Cambios en las recomendaciones de generación del token 2FA en sitios existentes

From Joomla! Documentation

Revision as of 06:05, 13 March 2021 by Pabloarias (talk | contribs) (Created page with "==Cuál es la causa==")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Other languages:
Deutsch • ‎English • ‎español • ‎français • ‎italiano • ‎中文(台灣)‎ • ‎中文(繁體)‎

Esta página incluye detalles sobre las correcciones de seguridad realizadas en Joomla 3.9.25 referentes a la configuración de la autenticación en dos pasos (2FA). Aquí puedes localizar un análisis de impacto así como recomendaciones para sitios existentes.

Errores de los que se ha informado

El JSST ha contactado con el investigador de seguridad Hanno Böck por dos incidencias en el código que han sido corregidas por esta actualización.

Versiones afectadas

Información General

Esto sólo afecta a la(s) versión(ones) de Joomla!:: 3.2.0 - 3.9.24

Cuál es la causa

Starting from Joomla 3.2.0 the Joomla core ships with core support of 2FA / TOTP. Up until 3.9.25 the implementation had two minor security flaws:

  • Usage of the insecure rand() function within the process of generating the 2FA secret.
  • Usage of an insufficient length for the 2FA secret according to RFC 4226 of 10 bytes vs 20 bytes

How it was fixed

Starting with Joomla 3.9.25 the Joomla core implementation has been updated to:

  • Use an secure random function (random_int; backported to older PHP version by the library paragonie/random_compat)
  • Use 20 bytes vs the old value of 10 bytes to generate the 2FA secret.

This issue has been coordinated with Akeeba Ltd as contributor of the original FOF codebase to the core.

Does this affect my website

As stated in the initial report provided by Hanno Böck he said regarding the usage of the insecure rand function:

[...] I consider the practical risk of this to be low. In order to attack this an attacker would have to know the approximate time when the person created his TOTP secret. PHP internally mixes in microseconds twice, so one could maybe reduce the possible options for the key to a few million, which is still very impractical for a real attack. [...]

And for the usage of 10 vs 20 bytes he said the following:

[...] The code by default uses 10 bytes for the secret. 10 bytes is 80 bits. The risk here is low. 80 bits is still outside of any practical attack. Nevertheless I think security requirements (and even recommendations) of the RFC should be followed, so I recommend changing this to 20 bytes (aka 160 bits). [...]

Based on that information the JSST came to the conclusion to obviously implement the changes as note above but this does explicit not mean that practically all 2FA tokes generated prior the patch have to be regenerated as they still work as expected and are still secure form a practical standpoint. It should also be obvious that the changes made here only affect secrets generated after this change.