OATH TOTP e / o Google Authenticator sono vulnerabili se un utente malintenzionato ha (N) codici precedenti?

7

Non sono un grande iniziatore di ipsec, quindi è un po 'strano ... ma sono sempre disposto a saperne di più.

Esistono attacchi noti contro OATH TOTP (algoritmo di Google Authenticator / Authy) se un utente malintenzionato ha un numero (non specificato) di passwords precedenti, come generato dall'app?

O, per dirla in altro modo: c'è qualche motivo per preoccuparsi che ci sia un record di OTP individuali che ho usato in passato? (Ad esempio, posso inserirli sulla riga di comando quando invoco uno strumento ... o dovrebbero essere inseriti come password, in modo silenzioso e interattivo, per evitare che vengano registrati?)

    
posta ELLIOTTCABLE 19.09.2013 - 20:55
fonte

2 risposte

13

I specifiche TOTP puntano, per l'analisi di sicurezza, a HOTP . HOTP utilizza un contatore, condiviso da entrambe le parti, e "risincronizzato" ogni volta che si verifica un'autenticazione riuscita; TOTP sostituisce quel contatore con la conoscenza del tempo corrente, che è anche un valore condiviso. In quanto tale, quasi tutte le analisi di sicurezza di HOTP si applicano a TOTP.

L' analisi della sicurezza di HOTP utilizza gli strumenti e le notazioni formali della crittografia, ma si riduce al seguente presupposto:

Let T denotes the time to perform one computation of H.  Then if A is
any adversary with running time at most t and making at most p oracle
queries,

                   Adv(A) <= (t/T)/2^k + p^2/2^n

In practice, this assumption means that H is very secure as PRF.

La parola importante qui è PRF : significa che la funzione "H" (HMAC/SHA-1 ) si comporta, nella vista dell'attaccante (che non conosce la chiave) come una funzione scelta "a caso" tra tutte le possibili funzioni. Diamo l'attaccante accesso a un "oracolo", che è una macchina che conosce la chiave, e calcola HMAC / SHA-1 su input scelti dall'attaccante; l'utente malintenzionato può inviare p tali query. L'espressione sopra significa che anche in queste condizioni, la probabilità che l'attaccante predice con successo, dopo tutte le sue domande, l'output di un input extra (che non ha inviato all'oracolo), è ancora molto basso (il "vantaggio" è quale probabilità in più di successo l'attaccante ha su pura fortuna).

Al momento, sembra che HMAC / SHA-1 si comporti come un PRF. Nessuno ha trovato alcuna indicazione contraria. Ciò vale anche di fronte alle note debolezze strutturali che sembrano consentire (teoricamente) alcune collisioni di calcolo SHA-1.

Da questo presupposto, la prova di sicurezza di HOTP (come esposto in RFC 4226) stabilisce il seguente risultato:

Suppose m = 10^Digit < 2^31, and let (q,r) = IntDiv(2^31,m).  Let B
be any adversary attacking HOTP using v verification oracle queries,
a <= 2^c - s authenticator oracle queries, and running time t.  Let T
denote the time to perform one computation of H.  If Assumption 1 is
true, then

     Adv(B) <= sv * (q + 1)/2^31 + (t/T)/2^k + ((sv + a)^2)/2^n

In practice, the (t/T)2^-k + ((sv + a)^2)2^-n term is much smaller
than the sv(q + 1)/2^n term, so that the above says that for all
practical purposes the success rate of an adversary attacking HOTP is
sv(q + 1)/2^n, just as for HOTP-IDEAL, meaning the HOTP algorithm is
in practice essentially as good as its idealized counterpart.

Questo ultimo paragrafo è quello che state cercando: supponendo che HMAC / SHA-1 sia un PRF, è provato che dare accesso a molte delle precedenti password monouso non ha dato alcun vantaggio all'attaccante per aver indovinato il prossimo, almeno non più quello che otterrebbe da una versione "ideale" di HOTP in cui le password monouso sono ottenute attraverso la pura magia imprevedibile.

Riepilogo: non c'è bisogno di preoccuparsi. Resistenza di HOTP (e TOTP) alla situazione in cui sono state registrate molte password monouso precedenti è parte del modello di sicurezza di HOTP, ed è stato specificamente protetto da tale evenienza. Lo scudo qui si basa su un'ipotesi di sicurezza su HMAC / SHA-1, che, sebbene non dimostrato, è tanto buono quanto ciò che può ottenere (in particolare perché è del tutto possibile che il fatto che una famiglia di funzioni sia un PRF possa essere matematicamente impossibile da provare, vedi questo per ulteriori informazioni sull'argomento)

    
risposta data 19.09.2013 - 23:12
fonte
1

I token sono calcolati usando le librerie HMAC, in pratica:

HOTP(K,C) = Truncate(HMAC-SHA-1(K,C))

Dove K è il segreto memorizzato sul tuo telefono e sul server di convalida e C è il contatore (timestamp, in caso di TOTP).

HMAC-SHA-1 è una funzione unidirezionale, il che significa che dovrebbe essere impossibile ottenere K, C indipendentemente da qualsiasi valore precedentemente osservato. SHA-1 è noto per avere alcuni punti deboli, ma è ancora ragionevolmente attendibile per rendere tali attacchi poco pratici.

    
risposta data 19.09.2013 - 21:13
fonte

Leggi altre domande sui tag