it-swarm.dev

Perché Google paralizza il modulo PAM 2FA Google Authenticator?

Se attivi 2FA per Google Apps il segreto condiviso è di 160 bit. Il google_authenticator Il modulo PAM invece usa 80 bit per il segreto condiviso.

Secondo RFC 4226 :

R6 - L'algoritmo DEVE utilizzare un forte segreto condiviso. La lunghezza di
il segreto condiviso DEVE essere di almeno 128 bit. Questo documento
RACCOMANDA una lunghezza segreta condivisa di 160 bit.

Nota "DEVE" non "DOVREBBE". Ciò rende Google Authenticator non conforme.

Qual è la logica alla base di questo?

40
Akshay Kumar

commit iniziale per questo codice include già la lunghezza della chiave segreta "80 bit". Non è stato modificato in seguito.

Ora analizziamo le cose in modo più critico. HOTP è specificato in RFC 4226 . L'autenticazione utilizza un "segreto condiviso", che è il valore di cui stiamo parlando. Cosa dice RFC 4226 al riguardo? In sostanza, esiste un requisito in sezione 4 :

R6 - The algorithm MUST use a strong shared secret.  The length of
the shared secret MUST be at least 128 bits.  This document
RECOMMENDs a shared secret length of 160 bits.

E poi sezione 7.5 spiega dettagliatamente vari metodi per generare il segreto condiviso.

Ora il google_authenticator codice genera un segreto condiviso a 80 bit con /dev/urandom e quindi procede a codifica questo segreto con Base32 : questa codifica associa ciascun gruppo di 5 bit a un carattere stampabile. La stringa risultante è quindi composta da 16 caratteri, che sono scritti "così come sono" in un file, con ASCII, nel senso che nel file il segreto condiviso ha lunghezza ... 16 byte, ovvero 128 bit. È quindi possibile che la confusione iniziale deriva da ciò: ciò che è memorizzato ha una lunghezza che può essere vista, in un certo senso, conforme al requisito R6 di RFC 4226.

Naturalmente, la RFC parla del "segreto condiviso" chiamandolo " [~ # ~] k [~ # ~]" in sezione 5.1 e quindi procede utilizzarlo come chiave per HMAC ( sezione 5. , passaggio 1). Con il segreto condiviso generato con lo strumento da riga di comando in google_authenticator, ciò che entra in HMAC è in realtà una sequenza di 80 bit, non 128 bit, anche se questi 80 bit risultano essere codificati come 128 bit quando memorizzati (ma vengono decodificati di nuovo a 80 bit al momento dell'uso). Pertanto, questo segreto a 80 bit non può davvero, in modo legalistico, soddisfare il requisito R6 di RFC 4226. Tuttavia, la confusione sulla "lunghezza" (dopo o prima della codifica) può spiegare questa caratteristica di google_authenticator.

Si noti, tuttavia, che questo è solo per lo strumento da riga di comando che può essere utilizzato per generare il segreto come passaggio iniziale. Il resto del codice supporta valori segreti più lunghi.

(Un'altra teoria è che l'autore voleva testare il suo codice e, in particolare, testare la situazione in cui non esiste un codice QR. In tal caso, l'utente deve digitare il codice e un segreto a 80 bit è più facile da digitare rispetto a un segreto a 128 o 160 bit. Probabilmente, l'autore ha prima usato un breve segreto per facilitare lo sviluppo e successivamente ha dimenticato di riportarlo alla sua lunghezza nominale in seguito. Questo tipo di incidente si verifica abbastanza spesso.)


È fondamentale? Con il cappello del mio crittografo, devo rispondere: no. Una chiave segreta a 80 bit è ancora abbastanza forte contro la forza bruta, perché anche con molta GPU, 279 le valutazioni di HMAC/SHA-1 impiegheranno ancora un po 'di tempo (con una chiave a 80 bit, il costo medio della forza bruta è quello di provare metà delle possibili chiavi, ovvero 279 valutazioni). In effetti, HMAC/SHA-1 è considerato "crittograficamente forte", il che significa che l'attacco più noto è la forza bruta sulla chiave. Mettiamoci delle figure:

HMAC/SHA-1 utilizza due invocazioni SHA-1. Quindi il costo dell'attacco è, in media, il costo richiesto chiamando SHA-1 280 volte. Questa pagina mostra benchmark con 2,5 miliardi di chiamate SHA-1 al secondo per una buona GPU. Se stai montando una fattoria di cracking, di solito utilizzerai una GPU di "fascia media", non un modello di prim'ordine, perché otterrai più potere per dollaro in quel modo. Supponiamo che tu usi 100 $ GPU che può fare 231 SHA-1 al secondo (un po 'più di 2 miliardi). Con un budget di un miliardo di dollari puoi avere dieci milioni di tali GPU e eseguiranno l'attacco in media ... 652 giorni.

Naturalmente, 10 milioni di GPU occupano abbastanza spazio e, cosa ancora più importante, usano una notevole quantità di energia. Se supponiamo che ciascuna GPU possa funzionare a 50 W (una cifra abbastanza ottimistica), ogni attacco avrà bisogno di un po 'meno di 8 TW.h (terawattora). Vivo in Canada, provincia del Québec, dove l'elettricità è nota per essere molto economica a causa di enormi dighe e sostanziali sovvenzioni governative, con un prezzo di circa 0,05 $ per kW.h (vedi i prezzi ) . Con questo prezzo, ogni attacco avrà un costo di circa 400 milioni di dollari solo per l'elettricità. Ciò non include i prezzi di raffreddamento, perché tutta questa energia diventerà calore e dovrà essere dissipata (in una certa misura, un inverno canadese può aiutare). Inoltre, nota che tutte le GPU assorbiranno collettivamente 500 MW, una quantità non discreta (che è circa la metà di una centrale nucleare ...).

Ciò equivale a quanto segue: in pratica, una chiave a 80 bit è abbastanza forte . Sarei nervoso se una chiave a 80 bit proteggesse il codice di lancio per i missili nucleari; tuttavia, se la dissuasione strategica fosse protetta dal 2FA di Google, sarei anche piuttosto nervoso per ... altri motivi.

Quindi possiamo dire che mentre questo segreto a 80 bit non è conforme e accademicamente "un po 'corto", è ancora abbastanza forte e non impone azioni immediate e drastiche. Sarebbe bello se il codice fosse corretto; il mondo non smetterà di girare se non lo è.

20
Thomas Pornin

Come ho già detto nel mio commento, ho già aperto un problema sul repository Google Authenticator. Tuttavia, non ci sono state risposte ufficiali dagli sviluppatori su di esso. Sembra che l'attività sul repository sia piuttosto stagnante.

Anche se probabilmente non c'è una buona spiegazione del perché Google abbia optato per 80 bit invece dei 160 bit raccomandati come da RFC, c'è una soluzione abbastanza semplice se questo è un problema importante.

Per quanto ne so, la dimensione del segreto è definita esclusivamente in libpam/google-authenticator.c sulla linea 39.

#define SECRET_BITS               80          // Must be divisible by eight

La modifica del valore da 80 a 160 funziona e non interrompe nulla per quanto posso dire. Questo potrebbe essere praticabile se si desidera davvero che il modulo PAM sia conforme all'RFC.

10
user10211