J3.x:Changes to the 2FA token generation recommendations for existing sites/it

Questa pagina include i dettagli sulle patch di sicurezza rilasciate con Joomla 3.9.25 riguardanti la configurazione 2FA. Qui puoi trovare un'analisi dell'impatto e anche raccomandazioni per i siti esistenti.

Errori segnalati

Il JSST è stato contattato dal ricercatore di sicurezza Hanno Böck ed è stato messo al corrente di due problemi all'interno del codice che sono stati risolti da questo aggiornamento.

Versioni interessate

Informazioni Generali

Qual è 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.