Dipende dall'implementazione del token.
Esistono 3 tipi di implementazioni e solo il primo è "vulnerabile":
1: alcuni token vengono consegnati dove il seme può essere calcolato dal serial hardware in modo deterministico. Questo può accadere se ordini un token dove puoi "usarlo con il tuo server senza bisogno di API" o qualcosa di simile a questo, qualcosa come un "token TOTP universale" o "token HOTP universale". Dovresti quindi rimuovere l'adesivo con il seriale dopo aver ricevuto il token, e in genere il serial sarà più difficile da indovinare.
In questo caso, qualcuno con la conoscenza della serie sarà in grado di calcolare i codici futuri.
2: Hai ordinato il token dal servizio cloud in questione:
Quindi non è un problema, come quando viene prodotto il tuo token, un file con i suoi numeri seriali e semi segreti, vengono creati e inviati al tuo provider cloud. (Alcuni modelli di token consentono persino al provider cloud di "reinizializzare" il token con i propri semi)
Quindi, il tuo provider cloud crea un database da questo file.
Quando inserisci la seriale sul sito del fornitore cloud, cerca solo il seme per quel particolare token e memorizza quel seme nel tuo account.
3: viene utilizzato un sistema token con un'API, in cui si ordina il token da un "provider di token" che fornisce anche un'API di autenticazione per i servizi di relazionamento di terze parti da utilizzare:
Altri sistemi di token, come il Symantec VIP, si affidano invece a un'API, dove si registra solo la seriale hardware con il provider cloud, solo la seriale è memorizzata nell'account. Quando si verifica un'autenticazione, il provider cloud invia una richiesta a Symantec Server, chiedendo se il codice "xxxxxx" è un codice corretto per la serie di token "xxxxxxxxxxxx". Questo è il motivo per cui un compromesso non può accadere anche se lo stesso token è registrato su più servizi.
E perché ti viene chiesto di fornire 2 codici secondari durante la registrazione del token:
Il motivo per cui ti viene richiesto di fornire 2 codici secondari è quello di garantire che il token sia utilizzabile, in modo da non bloccarti per errore dall'account. Questo processo funziona anche come un processo di risincronizzazione, in cui il servizio troverà la "sincronizzazione iniziale" del token, cercando quella particolare finestra in cui esistono questi 2 codici e la ricerca potrebbe passare attraverso tousands di codici per garantire che anche un Token pesantemente desincronizzato può essere registrato con il servizio.
Se viene fornito un solo codice, esiste la possibilità che il codice esista da qualche altra parte, poiché è probabile che ripetano 6 o 8 cifre e il server potrebbe accidentalmente impostare un valore di sincronizzazione iniziale errato sul token, lasciandolo bloccato.
Quando si esegue un processo di risincronizzazione, che può essere avviato dall'amministratore o dall'helpdesk, oppure può essere un processo automatico avviato da un numero di codici non validi, viene richiesto anche di fornire 2 codici secondari. Questa volta, non è necessario impedire una risincronizzazione non valida in quanto è molto improbabile, ma per aumentare la sicurezza poiché il server cercherà in genere circa 50-100 codici in avanti e anche 50-100 codici all'indietro (configurabili), il che renderebbe un utente malintenzionato potrebbe indovinare il codice se ne è stato utilizzato uno solo, ma ovviamente il server non tornerà mai indietro rispetto all'ultimo codice utilizzato in quanto ciò consentirebbe il riutilizzo dei codici token.
Tuttavia, in fondo, è che non dovresti condividere i token serial comunque, perché a volte il token serial può essere un dato di autenticazione parziale per il recupero dell'account, quindi con l'uso di token serial, un attacker potrebbe essere in grado di convincere l'helpdesk personell nel disabilitare 2FA per il tuo account con il tipo "Il mio token è diventato nero, c'è qualcosa di sbagliato in questo" e così, e il personale dell'helpdesk sta solo cercando di aiutare, e si innamora del trucco di social engineering.