Joomla! Documentation™

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

A partire da Joomla 3.2.0 il core di Joomla è dotato del supporto 2FA / TOTP. Fino alla 3.9.25 l'implementazione aveva due piccoli difetti di sicurezza:

• Uso della funzione insicura rand() nel processo di generazione del segreto 2FA.
• Uso di una lunghezza insufficiente per il segreto 2FA secondo RFC 4226 di 10 byte contro 20 byte

Come è stato risolto

A partire da Joomla 3.9.25 l'implementazione del nucleo di Joomla è stata aggiornata:

• 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.