Se capisco bene la tua domanda, l'attacco che stai proponendo è di forzare le password contro un server come questo, quindi una volta che ti mostra la schermata MFA, prova quella password su altri siti web che questo utente ha account su.

Questa è un'ottima domanda! Buona scoperta! Ma sembra che tu stia trascurando due punti:

1. Questo non è più debole che non avere MFA, che conferma anche la password corretta ... permettendoti di entrare.

2. Nessun hacker sano di mente proverà a forzare brutemente una password contro un server live che in genere ti limita a 5 tentativi al secondo. Oppure, nel caso dei grandi provider come GMail o Outlook, dispongono di complessi sistemi di rilevamento delle frodi che bloccano automaticamente l'IP di attività sospette. 99,999 ...% delle volte, la forzatura bruta delle password viene eseguita contro gli hash delle password rubati direttamente dal database su cui è possibile indovinare (m | b) illioni di password al secondo.

ol >

Quindi, anche se sono d'accordo con te sul fatto che qui c'è il potenziale per una perdita di dati, penso che il rischio sia minimo e di gran lunga superato dall'inconveniente dell'utente di dover armeggiare con il proprio portachiavi OTP solo per scoprire che sbagliano la loro password.

---

Aggiorna i commenti di indirizzamento poiché questa è diventata una domanda di rete calda:

Esistono due tipi di autenticazione a più fattori (noto anche come "2FA" o "MFA") a cui bisogna davvero pensare separatamente:

1. SMS o Push Notification 2FA : quando arrivi al Schermata 2FA invia un codice al tuo dispositivo che devi digitare. Per molti utenti, questo è probabilmente l'unico tipo di 2FA a cui sei stato esposto. L'attacco descritto nella domanda non funzionerà in questo caso perché l'utente riceverà un codice 2FA che non ha richiesto e saprà che c'è qualcosa che non va. Inoltre, eseguire il passaggio 2FA indipendentemente dal fatto che la password sia corretta è effettivamente dannoso in questo caso perché:

   • Un utente malintenzionato potrebbe potenzialmente far sì che l'utente riceva un'enorme bolletta mensile di dati / SMS o che il dispositivo si blocchi riempiendone la memoria di notifiche.
   • Indica anche quali utenti hanno abilitato 2FA e quali sono obiettivi facili.

2. 2FA "offline" utilizzando token di generazione di codice, app o smart card / chiavette USB abilitate per chiave pubblica (vedi immagine sotto). Questo è il tipo di 2FA utilizzato dal governo, dai militari e dalle società. Quindi, sebbene sia meno visibile agli utenti finali, è di gran lunga il tipo più importante di 2FA a causa del valore dei dati che protegge. In questo caso, non vi è alcuna notifica "incorporata" per l'utente quando un utente malintenzionato raggiunge la propria schermata 2FA. E di solito tutti gli utenti sono tenuti a utilizzare 2FA, quindi non c'è nulla di male nel trapelare quale utente ha 2FA abilitato, perché è tutti loro.

Immagina questo scenario per il caso 2: una VPN aziendale che si trova sopra Active Directory di Windows. Le VPN rivolte al pubblico vengono martellate tutto il giorno da chi indovina la password, quindi non c'è nulla di insolito in quei registri. Ma se riesco a far confermare la password dell'utente dalla schermata 2FA della VPN, posso andare al laptop e accedere con la certezza che non bloccherà l'account Windows, cosa che verrebbe sicuramente notata dall'utente / IT. La domanda indica correttamente una falla di sicurezza che il modello "è arrivato alla schermata 2FA e non ha inserito nulla / inserito qualcosa di sbagliato" dovrebbe certamente essere contrassegnato come più grave del tuo "nome utente / password errato" standard e dovrebbe notificare all'utente finale di ritirare la password.

Penso che questo non sia un problema. L'autenticazione a più fattori non serve a impedire a qualcuno di indovinare la tua password, ma a impedire a chiunque di accedere ai tuoi account.

Quindi ora il cracker potrebbe avere accesso a tutti gli account utente sul Web, molti dei quali probabilmente non hanno implementato l'MFA, lasciando l'utente completamente vulnerabile agli attacchi.

Un malintenzionato non proverà a indovinare una password su Google che non proverà anche per la banca o Facebook o simili. Solo perché ora è stato rivelato che si tratta di una password valida, l'attaccante non è più vicino a compromettere altri account. La password indovinata doveva provenire da una culla di ipotesi ad alta probabilità, perché una vera forza bruta non funzionerà mai su un sistema live.

Se potessi dimostrare che i siti che utilizzano 2FA hanno algoritmi anti-supposizione peggiori (I scommetterei che sono almeno altrettanto buoni se non migliori) rispetto ai siti che non offrono 2FA, il tuo punto sarebbe valido poiché un utente malintenzionato potrebbe abusare di uno e ruotare verso l'altro. In realtà è probabile che sia vero il contrario, i siti che investono in 2FA stanno anche investendo in sistemi anti-indovinare allo stesso tempo.

In teoria, sì, questa è una possibilità (a condizione che il sito che implementa 2FA non abbia limiti di velocità o rilevamento di frodi di alcun tipo, come sottolineato dalle altre risposte).

In pratica , c'è anche il fattore di usabilità a cui pensare. Immagina di aver creato un modulo di accesso che richiede a un utente 2FA a ogni tentativo di accesso, comunicando all'utente che il tentativo non è andato a buon fine dopo il passaggio 2FA e senza mai dirgli se era la password o il token 2FA non valido.

2FA è già un enorme dolore al collo per cominciare: ogni volta che effettuo l'accesso, non devo solo digitare il mio nome utente e la password, ma trovare il mio telefono (che potrebbe essere in un'altra stanza), sbloccarlo, vai alla mia schermata iniziale, trova la mia app 2FA e trova il sito giusto nell'elenco. Quindi, il codice è inevitabilmente a cinque secondi dalla scadenza, quindi devo aspettare che ne venga fuori uno nuovo o provare a digitarlo molto velocemente prima che scada.

(sistemi 2FA che utilizzare SMS o notifiche push sono migliori a questo proposito, perché arrivano sul mio smartwatch o, nel caso di un utente che non possiede uno smartwatch, il loro lockscreen. Nello schema che stiamo considerando, però, sarebbe consentire a un utente di infastidirmi con notifiche / SMS infiniti purché conoscano il mio nome utente, perché non devono ottenere la password corretta per attivare un tentativo di 2FA. Ho anche sentito che in alcuni paesi gli operatori telefonici ti fanno pagare per ricevere messaggi SMS, quindi in quei posti questo genere di cose sarebbe anche peggio per gli utenti.)

Se fai ripetere ai tuoi utenti tutto questo due volte quando sbagliano la password, l'intero processo diventerà molto più doloroso e di conseguenza potresti anche ritrovarti con meno persone che utilizzano 2FA, rendendo i tuoi utenti meno sicuri o n nella media.

Per i sistemi in cui 2FA / MFA è "opzionale" come Gmail o Outlook.com, il servizio deve bilanciare il fattore fastidioso dell'utilizzo del metodo a due fattori e la sicurezza che offre al loro sito . In un mondo perfetto, gli utenti avrebbero password complesse e univoche per ogni sito e utilizzerebbero sempre 2FA quando disponibili, ma nel mondo reale hai ragione: gli utenti avranno la stessa password su una dozzina di siti e un fattore 2 meccanismo che non blocca automaticamente l'account e avvisa l'utente dopo alcuni tentativi di accesso non validi in una finestra relativamente piccola potrebbe portare a una situazione in cui l'attaccante tenta pazientemente alcune probabili ipotesi fino a quando non arriva al prompt 2FA, a quel punto sapere di avere una combinazione nome utente + password valida. Con tutti i database di password altamente pubblici compromessi su siti di grandi dimensioni (come LinkedIn, tra molti altri) che utilizzano il tuo indirizzo e-mail come accesso, un utente malintenzionato può indovinare logicamente la password di un utente in modo relativamente semplice se l'utente non si è mai preoccupato di aggiornare altri siti , ma solo quello "rotto".

Per le app critiche per la sicurezza (come una delle tante su cui lavoro), il prompt di accesso richiede nome utente, password e valore a due fattori contemporaneamente ed è un'autenticazione "tutto o niente", e non ti diciamo PERCHÉ il tuo accesso non è riuscito, a meno che non sia perché la tua password è scaduta (il che presuppone che tu abbia inserito la password corretta, ma ti richiederà solo di cambiarla e inserirla di nuovo con un altro valore 2FA per ottenere effettivamente l'accesso all'applicazione). Quell'applicazione ha una base di utenti "captive" e il 2FA è richiesto dalla politica, quindi non è direttamente paragonabile ai siti "2FA-optional" che hai menzionato nell'OP.

Fondamentalmente, tuttavia, sono d'accordo con i commenti precedenti sul fatto che un "token-on-demand" è più sicuro di un token "offline" (come RSA o Google Authenticator) se hai intenzione di eseguire l'autenticazione in due passaggi perché l'utente saprà subito che qualcuno sta tentando di accedere al proprio account in virtù dei messaggi SMS inaspettati, o "password errata" o una stringa di 2 fattori valida nel caso in cui l'aggressore lo indichi correttamente. Se il sito invia SOLO il valore SMS a 2 fattori in caso di accesso riuscito, è inutile per il punto che hai menzionato, per far sapere all'utente PRIMA che l'attaccante ottenga effettivamente la password corretta. L'utente otterrebbe la stringa a 2 fattori valida solo quando l'aggressore aveva la password corretta. A quel punto, probabilmente è troppo tardi e l'aggressore sta già provando le stesse combinazioni di nome utente + password su altri siti che non hanno 2FA e l'utente dovrebbe essere al computer e affrettarsi per cambiare ogni password su ogni sito lo usano su, che se stanno riutilizzando la stessa password ovunque, è praticamente impossibile perché non le ricorderanno tutte.

In definitiva, dipende dall'implementazione individuale fino a quanto può essere dannoso un 2FA per altri siti utilizzati dallo stesso utente. Nel migliore dei casi, è un accesso all-in-one come ho descritto, in cui l'attaccante dovrebbe in qualche modo avere anche il proprio dispositivo 2FA o "stringa magica" (token di inizializzazione per qualcosa come Google Authenticator), e se lo hanno anche loro , l'utente è già stato ben compromesso.