Se il tuo modello suggerisce di farlo anche senza il nome utente;
Non puoi farlo perché non tutti i token 2FA sono uguali. Ogni token è univoco (chiave segreta) e pertanto è necessario identificare l'individuo che tenta di accedere prima di sapere quale token si sta trattando per controllarlo.
Nel modo in cui suggerisci di inviare qualsiasi codice token verrà immediatamente convalidato a un utente sconosciuto il cui token è valido in quel momento, o nessuno, che nei grandi siti Web con molte centinaia di migliaia di utenti aumenta la probabilità di colpire il codice corretto per ognuno di questi utenti. Soprattutto perché la 2FA moderna di solito utilizza un tipo di finestra che consente ai codici di rimanere validi prima e dopo l'attuale iterazione corretta (tenendo conto della differenza di orario e di altre fonti di differenza oraria). Quindi ogni utente potrebbe probabilmente avere molti codici validi disponibili in un momento, aumentando ulteriormente le possibilità di successo.
Non sono sicuro che saresti in grado di nascondere le informazioni dell'utente se hanno digitato la password sbagliata. Sono d'accordo che non si invia un codice (nel caso di sms o codici di posta elettronica), ma se l'utente non capisce che il sito ha avuto un problema e qual è il problema, crea un'esperienza frustrante per loro (come sottolineato nei tuoi contro della parte 2). Le aziende odiano i clienti frustrati molto più di quanto non odiano la sicurezza inferiore.
Infine, ciò creerebbe un modo per gli aggressori di eseguire spam provenienti da un'attività legittima nel caso di SMS e codici di posta elettronica. Facendo clic sul pulsante invia il mio codice per tutti i codici di sempre, anche con il defaticamento diventerà fastidioso se continua a comparire ogni raffreddamento.
Se tuttavia nel tuo modello suggerisci che il nome utente è obbligatorio;
Se il nome utente e il codice sono obbligatori e viene applicato un periodo di defaticamento per prevenire gli attacchi, consiglierei comunque di non farlo. In tal caso, conoscendo solo il nome utente, posso eseguire un DOS su quell'utente, per sempre, con poco o nessun sforzo. Basta specificare il nome utente e continuare a inviare i codici. Più basso si effettua il raffreddamento, meglio è per l'utente e attacker, forzando brutemente essenzialmente una password intera a 6 o 8 cifre. Più lungo è il raffreddamento, peggio per l'utente e migliore per l'attaccante che fa un DOS. In entrambi i casi l'utente perde, l'attaccante vince.
Per riassumere le ragioni per cui penso che Internet sia incentrato su questo sistema sono come tali:
- I sistemi di nome utente / password erano già in uso al momento e l'hardware 2FA era il primo ad arrivare, il che significa che era assolutamente necessario sapere chi era l'utente per primo.
- Le implementazioni 2FA, anche quelle in software (il tipo da inviare a e-mail e SMS) sono spesso le stesse metodologicamente dei telecomandi hardware. Così hanno lo stesso requisito di identificazione.
- I server sono bravi a gestire un flusso di richieste in caso di attacchi, gli utenti finali no.
- È più semplice verificare l'identità di qualcuno con le credenziali predefinite direttamente con il server, anzichè affidarsi a una moltitudine di sistemi di cui non si è certi al momento attivi (server01 > servizio sms > GSM > air > Tower > iPhone > Utente > internet > ... > server01).