Non sono precisi perché non devono farlo e un linguaggio preciso potrebbe confondere alcuni utenti.

Potrebbero dire, ad esempio, "Non dovresti condividere codici inutilizzati inferiori a un'ora con nessun altro e nessuno di Google chiederà mai questo codice. "

Io e te sapremmo cosa significano. Mio suocero e mio nonno non sapranno perché, però. Mio suocero è un esempio specifico di una persona che vedrebbe che ci sono momenti in cui può condividere codici e qualcuno che lo truffa dal suo controllo di sicurezza sociale avrà accesso anche alla sua posta elettronica. (Sì, la maggior parte della sua posta in arrivo riguarda le sostanze chimiche per il controllo mentale aggiunte alle scie di condensazione e il modo in cui le eruzioni solari causano i terremoti, ma potrebbe anche consentire a qualcuno di accedere al suo conto bancario.)

Come è stato sottolineato nei commenti, ci sono altri esempi di situazioni che sono condizionatamente pericolose, ma le persone semplicemente non includono le eccezioni. Ad esempio: "Non guardare mai la canna di un'arma da fuoco [a meno che tu non abbia svuotato la camera]" o "non inserire mai il dito in una presa di corrente [a meno che tu non abbia spento la corrente a quella presa]."

Poiché un token usato o scaduto è inutile per tutti, non ha senso conservarlo, condividerlo, proteggerlo, eliminarlo o aggiungere eccezioni ai consigli generali sulla sicurezza.

Lo capisco da personale esperienza che ci sono utenti che faranno cose stupide quando gli fai sapere che ci sono casi limite e sfumature per la sicurezza. Sapendo che, se dovessi scrivere un simile avvertimento ai miei utenti, renderei la mia dichiarazione il più ampia e generale possibile.

Serve a prevenire attacchi di ingegneria sociale contro di te. Immagina, ad esempio, di aver effettuato l'accesso al tuo account Gmail a due fattori su un computer pubblico ombreggiato in cui un keylogger ha registrato il tuo indirizzo email e la tua password (ma non sei stato in grado di usarli mentre eri loggato), ma hai l'autenticazione a due fattori abilitata e ti sei ricordato di disconnetterti alla fine della sessione. Il tuo account è ancora al sicuro (anche se ancora una volta, è meglio non accedere ai tuoi sistemi utilizzando computer pubblici imprecisi; perché anche con l'autenticazione a due fattori qualcuno sofisticato potrebbe comunque fare cose potenzialmente dannose sul tuo account nella finestra mentre eri connesso) .

Gli aggressori ora hanno il tuo indirizzo email e la tua password. Per accedere al tuo account (ad esempio per utilizzare il tuo indirizzo e-mail per reimpostare le password per altri sistemi, come ordinare cose online, accedere a conti bancari, inviare spam o altro caos), devono superare il sistema di autenticazione a due fattori. Quindi ti contattano, fingono di essere Google e cercano di indurti a rispondere con il codice di autenticazione effettivo, in modo che possano accedere completamente al tuo account. Forse ti chiamano al telefono (numero falsificato che sembra associato a Google Inc) e dicono "vediamo che hai configurato l'autenticazione a 2 fattori, prima di poter procedere ho bisogno che tu ci dica il codice appena inviato", ecc.

I token scaduti o già utilizzati non hanno importanza, ma vogliono solo farti prendere l'abitudine di non divulgare queste informazioni a terzi.

Potrebbe non essere applicabile per fornire il codice a qualcuno prima dell'uso, tuttavia anche se qualcuno conosce il tuo nome utente e la tua password ed è stato in grado di ottenere un codice inutilizzato e quella persona a cui accedere dovrebbe essere generato un nuovo codice per la nuova sessione . giusto?

Sbagliato. Presumo tu stia parlando di un codice TOTP generato ad esempio dall'app Google Authenticator. TOTP funziona memorizzando un segreto condiviso sul client e sul server (il tuo telefono e i server di Google). Per l'autenticazione, sia il client che il server utilizzano il segreto come una chiave HMAC per eseguire l'hashing dell'ora corrente, quindi troncarlo a un valore di n cifra (spesso 6 cifre, a volte più lunghe ).

TOTP non è legato in alcun modo a una sessione, è interamente basato su un segreto condiviso e l'ora corrente.

Mi manca qualcosa, è lì qualche motivo per non condividere l'unico codice temporale, specialmente la parte su uno sconosciuto casuale che lo chiama e lo chiede? Inoltre dovrebbe essere scaduto da tempo prima che qualcuno avesse la possibilità di chiamarti e chiederlo in futuro.

Immagino che stiano cercando di impedire alle persone di cadere in truffe quando qualcuno te lo chiede per inviare loro il codice corrente . Dopo che il codice è stato utilizzato o dopo che è trascorso un tempo sufficiente per renderlo non più valido, il codice è inutile.

Più vecchi codici possono contenere informazioni sufficienti per consentire la forzatura bruta del segreto condiviso, ma che richiede almeno un attacco preimage a SHA-1, che è ancora abbastanza irrealizzabile (cioè i codici permetteranno loro di dire se qualche particolare ipotesi per il segreto condiviso è corretta, ma potrebbero trascorrere diverse vite indovinare e non trovarlo mai).

Questo vale per molti consigli nella comunità della sicurezza.

La linea che divide "buona pratica" e "cattiva pratica" dovrebbe essere coerente, ma spesso non lo è. O puoi romperlo ed è brutto o non puoi ed è buono, giusto?

Sfortunatamente non è così che tende a funzionare. In particolare la parte offensiva e quella difensiva tracciano linee sulla sabbia in modo diverso. Sebbene la stessa domanda rotta o non sia il cuore della questione in pratica, ignora molte aree grigie tra il "buono" e il "cattivo" che nessuna delle parti vuole affrontare, il che porta a molte domande imbarazzanti come la mia preferito "Quanto è grave MD5?".

Sfortunatamente non esiste un modo semplice per aggirare questo problema. C'è molta area grigia nella crittografia in quanto riguarda ciò che le persone non possono fare e che è quasi impossibile da provare o evitare. Anche quando non c'è alcuna ambiguità, quanto tempo ci vorrà, e con quale kit, perché qualcosa sia forza bruta prima che sia sicuro? I suoi minuti chiari su un desktop medio non sono buoni e miliardi di anni su tutti gli attuali computer dell'umanità sono probabilmente abbastanza buoni per la maggior parte delle cose, ma il confine c'è nel mezzo. Non c'è risposta a questo. L'unico modo per essere al sicuro è se la parte difensiva insiste sempre su condizioni più rigide di quelle che la parte offensiva accetterebbe come vulnerabile .

Il risultato da portare a casa è:

Non dovresti aspettarti che il consiglio difensivo si allinei esattamente con gli attacchi vitali, non è il loro lavoro ed è invariabilmente una linea sfocata complessa che è quasi impossibile da correggere e gli errori possono essere a dir poco problematici.

Quindi sbagliamo dalla parte della cautela. Soprattutto se questo fa poco male.

dr jimbob è completamente corretto. Ingegneria sociale. In particolare, un attacco di ingegneria sociale quando l'aggressore ha la tua password. Posso immaginare uno scenario in cui un database utente insicuro viene forzato. Immagino che un discreto numero di utenti potrebbe essere associato a un numero di telefono, potrebbe anche essere nel database. Man mano che le password vengono violate e viene associato un numero di telefono, inviarlo a un IVR Twilio. Se rispondono, l'IVR dice loro che il loro account potrebbe essere stato compromesso e verrà disattivato a meno che non inseriscano il codice di conferma che dovrebbero ricevere. Quindi attiva un login e se rispondono con il codice, sei dentro. Questo è esattamente il motivo per cui si dice che nessuno lo chiederà mai. Come accennato, quelli usati non hanno valore, ma convincerti a rinunciare a uno inutilizzato è d'oro.

La mia risposta è sbagliata.

Questi codici sono generati da "qualche algoritmo". Anche se qualcuno conosce questo algoritmo, non conosce il punto di partenza o la posizione corrente nella sequenza di codici calcolabili in cui si trova attualmente l'algoritmo.

Se qualcuno avesse abbastanza codici E conoscesse l'algoritmo potrebbe, in teoria, capire dove si trova l'algoritmo nella sequenza e iniziare a calcolare nuovi codici.

Anche se, penso che questo potrebbe applicarsi solo a quei token hardware che ottieni, ad esempio, accedendo al tuo MMORPG preferito

Altamente improbabile che qualcuno possa elaborare entrambe le informazioni richieste per rompere il sistema.