Changes to the 2FA token generation recommendations for existing sites

From Joomla! Documentation

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

This page includes details about the security patches released with Joomla 3.9.25 regarding the 2FA setup. Here you can find an impact analyse and also recommendations for existing sites.

Errors reported

The JSST has been contacted by the security researcher Hanno Böck and has been made aware of two issues within the code that have been fixed by this update.

Versions affected

General Information

This pertains only to Joomla! version(s): 3.2.0 - 3.9.24

What is the cause

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.