2FA perché non chiedere il codice prima della password

8

Quindi nella maggior parte dei siti web sulla pagina di accesso è necessario inserire nome utente e password per es. Facebook dove inserisci username e password e poi invia il modulo. Altri siti web ti chiedono separatamente, ad es. Google dove inserisci username e invio, quindi password e invio ecc.

Nel caso in cui venga utilizzato il secondo schema - nome utente, quindi invio ecc. Perché non utilizzare prima il codice SMS?

La mia idea è che ciò impedirebbe agli utenti di indovinare o bruteforcing della password, che comunemente viene utilizzata su altri servizi come la posta elettronica, che spesso possono essere utilizzati per sbloccare l'account dall'autorizzazione SMS.

Un altro motivo è che questo fornirebbe all'utente informazioni dirette sul tentativo di accesso.

Modifica: mi sono reso conto che non ho detto che 2FA non è richiesto, ma piuttosto opzionale, in modo simile a Facebook o Google.

Mi piacerebbe anche presumere che il processo 2FA non sia imperfetto: l'utente non può impostare un numero non valido e il numero viene verificato al momento dell'impostazione. Il numero sarebbe stato controllato inviando il test OTP che sarebbe necessario per confermare che il numero è corretto.

    
posta vakus 08.04.2017 - 16:11
fonte

3 risposte

10

TL; DR La sicurezza è difficile e anche piccole modifiche al funzionamento dei protocolli di sicurezza possono aprire attacchi inaspettati. Mentre può sembrare a prima vista come mettere la 2FA prima che la password aiuti a proteggere la password, in realtà apre attacchi molto peggiori. Diamo un'occhiata!

Il problema che stiamo cercando di risolvere

Secondo la tua domanda, il problema che stai cercando di risolvere è la forzatura brute della password. Questo è un po 'falso perché le persone incrinano le password contro i furti o le perdite tra gli hash delle password, le persone non usano la forza bruta contro i server live, perché cose come la limitazione della velocità fanno già un ottimo lavoro per risolvere questo problema. Detto questo, diamo un'occhiata ai diversi tipi di 2FA e cosa accadrebbe se la 2FA passasse prima della password.

App di generazione del codice

alias algoritmo a tempo solo basato sulla password (TOTP) , ad esempio, l'autenticatore di Google :

Sonod'accordocontesulfattochenonriesco,incimaallamiatesta,apensareaunmotivopercuimetterequestoperprimoindebolirebbeilprotocollodiautenticazione.

Appdinotifica

Alcuni2FAsonoprogettatiperfarapparireunanotificasultelefonoanzichéfornireuncodice,adesempiol'AutenticatoreBlizzard:

Fare ciò che suggerisci di mettere questo prima della password in realtà sarebbe pericoloso perché porta ad un attacco denial-of-service: l'utente malintenzionato martella l'account di un utente in modo che ci siano notifiche quasi costanti sul telefono, impedendo loro dall'essere in grado di utilizzare il proprio telefono e / o costringerli a disattivare i 2FA per fare in modo che le notifiche si fermino (e indeboliscano il loro account).

Codici SMS

aka inviare una password One-Time al telefono via SMS.

Questo ha lo stesso problema delle app di notifica in quanto porta ad un evidente attacco denial of service, ma è peggio perché in alcuni luoghi i gestori telefonici addebitano gli SMS in entrata, quindi l'utente malintenzionato può costringere l'utente a pagare un enorme telefono cellulare bollette.

Sommario

Dei tre tipi di app 2FA che ho menzionato, la tua proposta è neutrale per uno e dannosa per gli altri due.

Inoltre, prima inserire il passo 2FA per gli autori di attacchi che l'utente ha attivato 2FA e quali no. Fondamentalmente dicendo loro chi sono gli obiettivi facili.

Infine, la notifica e il server 2FA basato su SMS hanno un altro scopo importante: un allarme per dirti quando la tua password è stata violata. Se ricevo una notifica 2FA che non mi aspettavo, è ora di cambiare la mia password.

Mi piace il fatto che tu stia pensando fuori dagli schemi e sfidi il modo in cui stanno le cose. La sicurezza è dura, ma non scoraggiarti nel fare più domande, questo è stato divertente rispondere.

    
risposta data 10.04.2017 - 16:41
fonte
5

È così che gli utenti che commettono un errore non attendono indefinitamente un OTP che non verrà mai.

Immagina il flusso di lavoro se la password monouso (OTP) è stata preceduta da una password. Sarebbe come questo:

  1. L'utente inserisce il nome utente
  2. Sistema cerca il nome utente per trovare il numero di cellulare

    a. Se il nome utente è valido e il numero di telefono esiste, il sistema invia OTP

    b. Se nessuno dei due esiste, il sistema non invia nulla

  3. In entrambi i casi , il sistema visualizza "Abbiamo inviato una password unica al numero di telefono associato al tuo account".

Perché "in entrambi i casi", potresti chiedere? Perché il messaggio è lo stesso in entrambi i casi? Vedi il cheat di autenticazione OWASP che ci dice:

An application should respond with a generic error message regardless of whether the user ID or password was incorrect. It should also give no indication to the status of an existing account.

Correct Response Example

-"Login failed; Invalid userID or password"

Incorrect Response Examples

  • "Login for User foo: invalid password"

  • "Login failed, invalid user ID"

  • "Login failed; account disabled"

Il motivo del messaggio generico è di evitare di fornire qualsiasi segnale che un hacker potrebbe utilizzare per l'agricoltura degli ID utente.

Ora continuiamo il nostro flusso di lavoro.

  1. Se l'utente immette un ID utente valido con un numero di telefono, riceve l'OTP e può inserirla.

  2. Se l'utente non ha inserito un ID utente valido o ha immesso un ID utente a cui non è associato alcun numero di telefono, l'utente attende indefinitamente .

Quindi ora vediamo il problema. Se l'utente commette un errore, il sistema non può dirle che ha commesso un errore e dovrà attendere l'OTP a tempo indeterminato. Questo è diverso dall'autenticazione della password, dove il feedback è immediato.

Questo intero problema scompare se la password è selezionata per prima. Una volta che l'utente è autenticato con il primo fattore, abbiamo già stabilito che l'ID utente è valido, e va bene comunicare loro se non hanno mai impostato un numero di telefono nell'account.

Anche altri casi d'uso sono interessati

Anche questi altri casi d'uso diventano UX più poveri, o sono difficili da implementare a causa dei requisiti di sicurezza:

  1. L'utente ha più di un telefono.
  2. L'utente ha cambiato telefono recentemente.
  3. L'utente ha erroneamente ricordato il suo ID utente
  4. L'utente ha uno stato bloccato
  5. La casella degli SMS dell'utente è piena
  6. Limitazione del vettore, ad es. Limite SMS superato o cliente nelle raccolte
  7. Telefono perso / rubato
risposta data 10.04.2017 - 13:48
fonte
1

Questo è per motivi di spam.

Ciò consente a un utente malintenzionato di scorrere i nomi utente (principalmente, questi sono pubblicamente disponibili o molto facili da indovinare) in modo che il sito invii un lotto di messaggi / messaggi inutili a tutti. Il sito Web verrà quindi inserito nella lista nera come "spammer".

E questo non può essere assicurato, tranne chiudendo tutti gli accessi per alcuni minuti (se continui a inviare spam a un solo account, come detto in un commento, puoi rifiutare di inviare un altro OTP se ne è già stato chiesto qualche minuto fa, ma questo non può essere fatto dal punto di vista del sito web.

Chiedere la password per prima cosa blocca questo tipo di attacco, dal momento che dovresti conoscere anche la password di tutti.

    
risposta data 10.04.2017 - 15:53
fonte

Leggi altre domande sui tag