J3.x

Modifiche alle raccomandazioni per la generazione di token 2FA per i siti esistenti

From Joomla! Documentation

This page is a translated version of the page J3.x:Changes to the 2FA token generation recommendations for existing sites and the translation is 100% complete.

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

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

Questo riguarda solo la(e) versione(i) di Joomla!:: 3.2.0 - 3.9.24

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:

  • Utilizzare una funzione casuale sicura (random_int; backported alla vecchia versione di PHP dalla libreria paragonie/random_compat)
  • Usa 20 byte contro il vecchio valore di 10 byte per generare il segreto 2FA.

Questo problema è stato coordinato con Akeeba Ltd come contributore della base di codice originale di FOF al nucleo.

Questo influisce sul mio sito web

Come dichiarato nel rapporto iniziale fornito da Hanno Böck, egli ha detto riguardo all'uso della funzione rand insicura:

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


E per l'uso di 10 contro 20 byte ha detto quanto segue:

[...] 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). Dovrebbe anche essere ovvio che i cambiamenti fatti qui riguardano solo i segreti generati dopo questo cambiamento.