I siti 2FA perdono informazioni confermando una password corretta?

Se sto capendo correttamente la tua domanda, l'attacco che stai proponendo è una password a forza bruta contro un server come questo, quindi una volta mostrata la schermata MFA, vai a provare quella password su altri siti web che questo utente ha account on.

Questa è una bella domanda! Buona scoperta! Ma sembri trascurare due punti:

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

2. Nessun hacker sano di mente tenterà la bruta-forzatura di una password contro un server live che tipicamente limita il numero di 5 ipotesi al secondo. O 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 ...% del tempo, la forzatura brute della password viene eseguita contro gli hash delle password rubati direttamente dal database su cui è possibile indovinare (m | b) illions of passwords al secondo.

Quindi, mentre 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 loro fob OTP solo per scoprire che si sbagliano " d la loro password.

Aggiorna i commenti sull'indirizzamento poiché questa è diventata una domanda sulla rete hot:

Esistono due tipi di autenticazione a più fattori (ovvero "2FA" o "MFA") che devono essere pensati separatamente:

1. SMS o notifica push 2FA : quando si arriva alla schermata 2FA, invia un codice al dispositivo che è necessario digitare. Per molti utenti, questo è probabilmente l'unico tipo di 2FA che sei stato esposto a L'attacco descritto nella domanda non funzionerà in questo caso perché l'utente riceverà un codice 2FA che non ha richiesto e saprà che qualcosa non va. Inoltre, fare il passo 2FA indipendentemente se la password è corretta è effettivamente dannoso in questo caso perché:

   • Un utente malintenzionato potrebbe potenzialmente far sì che l'utente ottenga un'enorme fattura mensile di dati / SMS o blocchi il suo dispositivo riempiendo la sua memoria di notifiche.
   • Perdono anche gli utenti che hanno attivato 2FA e che sono obiettivi facili.

2. 2FA "offline" utilizzando token di codice generatore, app o smart card / chiavette USB abilitate a chiave pubblica (vedi immagine sotto). Questo è il tipo di 2FA utilizzato da governo, militari e corporazioni. Quindi, mentre è 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" all'utente quando un utente malintenzionato accede alla sua schermata 2FA. E di solito tutti gli utenti sono obbligati a utilizzare 2FA, quindi non c'è nulla di male nel perdere quale utente ha attivato 2FA, perché è tutto.

Immagina questo scenario per il caso 2: una VPN aziendale che si trova sulla parte superiore di Active Directory di Windows. Le VPN rivolte al pubblico vengono martellate tutto il giorno da indovini di password, quindi non c'è nulla di strano in questi log. Ma se posso avere la password dell'utente confermata dalla schermata 2FA della VPN, posso accedere al loro laptop e accedere sicuro che non bloccherà l'account di Windows, che verrebbe sicuramente notato dall'utente / IT. La domanda indica correttamente un buco di sicurezza che il modello di "arrivato alla schermata 2FA e inserito nulla / inserito qualcosa di non corretto" dovrebbe sicuramente essere contrassegnato come più severo del tuo "nome utente / password errato" standard e dovrebbe informare l'utente finale ritirare la password.

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

So now the cracker may have access to all the user's accounts across the web, many of which probably don't have MFA implemented, leaving the user completely vulnerable to attacks.

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

Se si riuscisse a dimostrare che i siti che utilizzano 2FA hanno algoritmi di anti-ipotesi peggiori (scommetterei che sono almeno altrettanto buoni se non migliori) rispetto ai siti che non offrono 2FA, il punto sarebbe valido dal momento che un utente malintenzionato potrebbe abusarne uno e fare perno sull'altro. In realtà è probabile il contrario, i siti che investono in 2FA stanno anche investendo in sistemi anti-ipotesi contemporaneamente.

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

In pratica, c'è anche il fattore usabilità a cui pensare. Immagina di aver creato un modulo di accesso che richiede a 2FA un utente per ogni tentativo di accesso, comunicando all'utente che il tentativo non ha avuto esito positivo dopo il passaggio 2FA e non indicando mai se la password o il token 2FA non era valido.

2FA è già un enorme dolore al collo per cominciare - ogni volta che effettuo l'accesso, non solo devo digitare il mio nome utente e la password, ma trovare il mio telefono (che potrebbe essere in un'altra stanza), sbloccarlo, vai alla 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 velocemente prima che scada.

(I sistemi 2FA che usano gli SMS o le notifiche push sono migliori in questo senso, perché vengono visualizzati sul mio smartwatch - o, nel caso di un utente che non possiede uno smartwatch, la loro schermata di blocco. lo schema che stiamo considerando, però, consentirebbe a un utente di infastidirmi con notifiche / sms infiniti fintanto che conoscono il mio nome utente, perché non devono ottenere la mia password per attivare un tentativo 2FA. Ho sentito che in alcuni paesi i gestori telefonici ti caricano per ricevere messaggi SMS, quindi in quei luoghi questo genere di cose sarebbe ancora peggio per gli utenti.

Se fai in modo che i tuoi utenti passino tutto questo due volte quando ottengono la loro password sbagliata, l'intero processo diventerà molto più doloroso, e potresti addirittura finire con meno persone che usano 2FA come risultato, rendendo i tuoi utenti meno sicuro in media.

Per i sistemi in cui 2FA / MFA è "facoltativo" come Gmail o Outlook.com, il servizio deve bilanciare il fattore problematico dell'utilizzo del metodo a 2 fattori e della sicurezza che porta al proprio sito . In un mondo perfetto, gli utenti dispongono di password uniche e complesse per ogni sito e utilizzano 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'utente malintenzionato tenta pazientemente qualche ipotesi fino a quando non arriva al prompt 2FA, a quel punto essi sapere che hanno una combinazione di nome utente e password valida. Con tutti i compromessi del database delle password altamente pubblici su siti di grandi dimensioni (come LinkedIn, tra molti altri) che utilizzano il tuo indirizzo email come login, 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 proprio quello che era "incrinato".

Per le applicazioni critiche per la sicurezza (come una delle tante su cui lavoro), il prompt di login richiede nome utente, password e valore a 2 fattori contemporaneamente, ed è un'autenticazione "tutto o niente", e noi non lo facciamo ti dico PERCHÉ il tuo login è fallito, a meno che non sia perché la tua password è scaduta (il che presuppone che tu abbia inserito la password corretta, ma richiederà semplicemente di cambiarla e inserirla di nuovo con un altro valore 2FA per accedere effettivamente all'applicazione) . Quella applicazione ha una base di utenti "captive" e la 2FA è richiesta dalla politica, quindi non è direttamente confrontabile con i siti "2FA-opzionali" che hai menzionato nell'OP.

Fondamentalmente, tuttavia, concordo con i commenti sopra riportati 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ù di messaggi SMS imprevisti, o "password errata" o una stringa valida di 2 fattori nel caso in cui l'autore dell'attacco ottenga la risposta corretta. Se il sito invia SOLO il valore di 2 fattori SMS all'accesso corretto, allora è inutile per il punto che hai menzionato, per far sapere all'utente PRIMA che l'utente malintenzionato abbia effettivamente la password corretta. L'utente otterrebbe la stringa di 2 fattori valida solo se l'utente malintenzionato ha la password corretta. A quel punto, probabilmente è troppo tardi, e l'aggressore è già fuori a provare le stesse combinazioni di username e password su altri siti che non hanno 2FA e l'utente dovrebbe trovarsi su un computer e scramble per cambiare ogni password su ogni sito lo usano, che se stanno riutilizzando la stessa password ovunque, è praticamente impossibile perché non li ricorderanno tutti.

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