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:

[...] Ritengo che il rischio pratico di questo sia basso. Per poterlo attaccare un attaccante dovrebbe conoscere l'ora approssimativa in cui la persona ha creato il suo segreto TOTP. PHP mescola internamente i microsecondi due volte, quindi si potrebbe forse ridurre le possibili opzioni per la chiave a qualche milione, che è ancora molto poco pratico per un attacco reale. [...]

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

[...] Il codice di default usa 10 byte per il segreto. 10 byte sono 80 bit. Il rischio qui è basso. 80 bit sono ancora fuori da qualsiasi attacco pratico. Tuttavia penso che i requisiti di sicurezza (e anche le raccomandazioni) della RFC dovrebbero essere seguiti, quindi raccomando di cambiare questo a 20 byte (aka 160 bit). [...]

Il codice di default usa 10 byte per il segreto. 10 byte sono 80 bit. Il rischio qui è basso. 80 bit sono ancora fuori da qualsiasi attacco pratico. Tuttavia penso che i requisiti di sicurezza (e anche le raccomandazioni) della RFC dovrebbero essere seguiti, quindi raccomando di cambiare questo a 20 byte (aka 160 bit). It should also be obvious that the changes made here only affect secrets generated after this change.