Changes to the 2FA token generation recommendations for existing sites

From Joomla! Documentation

Revision as of 21:54, 28 December 2022 by Cmb (talk | contribs) (Corrected 'tokes' to 'tokens' and other markup changes.)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
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 analyses and also recommendations for existing sites.

Errors Reported[edit]

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[edit]

General Information

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

What is the Cause?[edit]

Starting from Joomla 3.2.0 the Joomla core ships with core support of 2FA/TOTP. Up until version 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[edit]

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?[edit]

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 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 implement the changes as noted above. This does not mean that practically all 2FA tokens 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.