Gli accessi simultanei possono verificarsi quando due utenti dispongono di entrambi i pezzi di informazioni di autenticazione a due fattori?

Dipende dal tipo di metodo OTP e dai dettagli di implementazione. Considerando che [RFC4226] [1] (l'OTP basato sul contatore) può essere interpretato come un impedimento al riutilizzo, come dice:

the server's counter value is only incremented after a successful HOTP authentication

Ma potrebbe non essere una garanzia che non ci sia una finestra temporale in cui lo stesso token HOTP sarà utilizzabile: i server di autenticazione multithread, con accesso simultaneo al database, potrebbero trascurare questo dettaglio.

Sta anche descrivendo questo:

RP3 - P SHOULD be implemented over a secure channel in order to protect users' privacy and avoid replay attacks.

Il che implica che non considerano la proprietà del protocollo proteggere dai token riutilizzati!

Allo stesso modo, per OTP basato sul tempo [RFC6238] [2] si spiega che è una buona protezione contro gli attacchi a ridurre la finestra temporale quando un token è valido. Ma menziona che il token è consumato , il che, a qualcuno potrebbe implicare che non può essere consumato di nuovo.

First, a larger time-step size exposes a larger window to attack. When an OTP is generated and exposed to a third party before it is consumed, the third party can consume the OTP within the time-step window.

Io personalmente non penso che un secondo fattore copiato dovrebbe essere valido, ma questo non è necessariamente quello che dicono gli standard, quindi potrebbero esserci delle variazioni su come questo viene interpretato. Altri venditori 2FA potrebbero anche non aderire a nessuno degli standard e potrebbero avere requisiti più rigidi o meno rigidi. Consentitemi anche di notare che potrebbe essere difficile implementare un metodo affidabile per bloccare tutto, tranne il primo utilizzo di un token all'interno di reti ampiamente distribuite, per tutti i casi.

Aggiornamento: ora che ci penso, posso vedere due ulteriori modi di impedire l'accesso con OTP duplicati: uno è in fase di preparazione: assicurati che ci sia solo il login della password che è in corso di accettare un OTP fino al timeout di autenticazione. L'altro è invalidare la sessione già concessa, oltre a quella duplicata. Questo può essere facile in un servizio basato sul Web, ma non altrettanto comodo con un accesso alla shell del computer.

Inoltre, non si può essere certi che l'utente valido sia il primo, quindi può essere un ostacolo anche per loro. Nel caso del vero MITM, l'attaccante può persino interrompere i tentativi autentici da parte loro in modo che non possa nemmeno esserci una notifica sullo stesso canale.

Come puoi vedere, non è così semplice accettare o non accettare l'OTP duplicato - devi considerare l'utente del servizio, come possono entrare in questa situazione e come saranno meno danneggiati o meglio serviti . Forse questo è il motivo per cui gli standard non discuteranno questi dettagli e lascialo a te.

[1]: link RFC4226-HOTP   [2]: link RFC6238-TOTP

È possibile avere due sessioni di accesso, ma occorrono due istanze sia del primo che del secondo fattore.

Il secondo fattore è generalmente un codice monouso, che scadrà dopo l'uso. Può anche scadere dopo un intervallo di tempo specificato se non utilizzato

Ad esempio; se il primo fattore è un nome utente / password, sarà lo stesso per entrambe le sessioni di accesso.

Se il secondo fattore è un token, sotto forma di un codice univoco a 6 cifre. Entrambi gli accessi richiedono il nome utente / password comuni e la propria istanza specifica del codice univoco a 6 cifre

Questa è ovviamente una generalizzazione e i diversi sistemi avranno le loro sfumature.

Per inciso, in un esperimento molto non scientifico ho provato a utilizzare il codice da un tentativo di accesso Google su un tentativo di accesso separato per verificare se il codice era portatile tra le sessioni e ha avuto esito positivo.