Se dovessi visualizzare pubblicamente il codice a 6 cifre dal mio autenticatore google, la sicurezza del mio account sarebbe diminuita oltre la sua durata di vita valida?
E se fosse il codice e il tempo in cui è stato generato?
E se si trattasse di N codici sequenziali?
Mi piacerebbe sapere perché o perché no per ogni caso.
Google Authenticator utilizza Algoritmo password una tantum basato sul tempo (" TOTP "), che funziona calcolando HMAC con una chiave segreta su un timestamp.
HMAC è un codice di autenticazione dei messaggi ("MAC"). Il requisito di sicurezza standard per un MAC è che sia in grado di resistere a falsificazione esistenziale (un utente malintenzionato che non conosce la chiave non dovrebbe essere in grado di falsificare (message, tag) coppie) in attacco di testo scelto adattivo (permettiamo che l'attaccante abbia la capacità di indurre il difensore a calcolare i tag per qualsiasi messaggio della scelta dell'attaccante e a imparare dai risultati precedenti quando sceglie nuove query).
Il risultato TOTP a 6 cifre tuttavia non è un output MAC diretto, ma piuttosto un troncamento di un tag MAC, quindi è possibile sollevare la questione se il MAC sia anche un MAC sicuro. Tuttavia HMAC, se usato con una buona funzione di hash, è anche ritenuto una funzione pseudo-casuale . I PRF sono automaticamente buoni MAC, e il troncamento di un PRF è anche un PRF, quindi il troncamento di HMAC è anche un buon MAC.
TL; DR: A meno che l'hacker non possa rompere HMAC-SHA1 in condizioni sfavorevoli, il che sarebbe una vera e propria battuta d'arresto per il mondo criptato nel suo complesso, non solo TOTP.
No. Questo è il punto di TOTP / HOTP. Che dovrebbe essere irrealizzabile, data una qualsiasi sequenza di codici validi, per generare codici futuri o ricreare il seme.
Il motivo è che l'algoritmo TOTP / HOTP, usa HMAC-SHA1 come hash, data la "sfida" (sia l'ora corrente UNIX o un contatore di usi) sia il segreto "seme" come chiave. L'output dell'hash risultante viene quindi troncato in base a una regola molto specifica.
Ciò significherebbe, nel primo caso, sarebbe impossibile da eseguire, poiché più chiavi valide genereranno il codice "corretto" a 6 cifre, ma risulteranno errate come codici futuri da queste "chiavi valide "non sarà valido.
Per montare con successo un attacco bruteforce contro un seme, avresti bisogno almeno di 2 codici di autorizzazione validi, possibili di più, e anche in quel caso, è impossibile (ad esempio, praticamente impossibile) farlo.
La prima definizione OTP in RFC 2289 basata su S / Key aveva anche questo requisito di progettazione.
Non era importante implementare l'autenticazione a due fattori, ma semplicemente proteggere la password o la passphrase. È stato semplicemente usato per evitare che la password attraversasse la rete - ovviamente si presumeva che la trasmissione potesse essere evesdropped o non criptata.
Quindi, come già detto, è un design fondamentale in tutti i sistemi OTP (S / Key, mOTP, OATH) per non permettere l'indovinare le password future basate su password usate.
Ma: con un algoritmo basato sugli eventi come HOTP puoi ovviamente creare elenchi OTP. Se generi un valore OTP ora e lo pubblichi su Internet ma non lo usi per il login, tutti gli altri possono usarlo. Viene invalidato solo quando viene utilizzato questo valore o quando viene utilizzato un valore successivo.
Leggi altre domande sui tag authentication multi-factor