Perché non chiedere una password e un token a 2 fattori allo stesso tempo?

Molti sistemi OTP ti consentono di ricevere un OTP via SMS / email. Quindi il sistema deve sapere quando inviarti un OTP.

Potresti suggerire che potrebbe esserci solo un pulsante "richiesta OTP" accanto al modulo. Ma poi chiunque può fare ripetutamente clic sul pulsante, il che significa che riceverai un'enorme quantità di email / SMS di spam.

Potresti suggerire di risolvere il problema limitando il tasso di OTP. Ma poi posso causare un rifiuto di servizio richiedendo la tua quota completa di OTP in modo che tu non possa accedere.

Una soluzione semplice a questo è solo inviare un OTP a un utente che ha fornito una password valida.

Non vedo alcun problema di sicurezza nel chiedere la password e un secondo fattore (token / biometrico) allo stesso tempo.

In effetti ciò aumenta la sicurezza del sistema, ma potrebbe influire sull'usabilità (esperienza utente) del sistema. Come è?

Diciamo che il sistema prende i due fattori di autenticazione (password e OTP) nello stesso punto e li prova. se entrambi corrispondono / passano consentono l'accesso altrimenti negano l'accesso.

supponiamo che ci siano 100 possibili password e 200 possibili codici OTP.

Se chiedi prima la password a un certo punto e poi quando ricevi una password valida chiedi l'OTP, allora un utente malintenzionato deve provare 300 volte (100 + 200) per entrare nel sistema .

Ma se chiedi la password e l'OTP allo stesso tempo, l'utente malintenzionato dovrà provare 20000 volte (100 * 200) per entrare nel sistema.

Ora, dal punto di usabilità se l'utente immette password errata o codice OTP, il sistema non gli dirà esattamente cosa è andato storto e potrebbe continuare a fare lo stesso errore, ad esempio inserendo la password errata perché pensa che sia corretto, mentre il vero problema con il suo token OTP o viceversa.

Potrebbero esserci un numero di motivi non tecnici, probabilmente un driver sarebbe la prestazione perché riduce il carico su qualche elaborazione sul back-end che non ha bisogno di essere richiamato.

Un'altra possibilità potrebbe essere quella di rendere più difficile la configurazione di un sito Web di phishing. Ora devi programmare più pagine. Inoltre, se mostri OTP solo quando c'è un nome utente e una password di successo (qualcosa che conosci l'autenticazione) può rendere difficile la creazione del sito di phishing e fornisce più pagine che l'utente può notare. Le immagini di sicurezza sono spesso note come valore minimo perché il processo è spesso nome utente, quindi mostra l'immagine di sicurezza (ad esempio SiteKey ), quindi password. Tuttavia, se si modifica solo questo con due fattori come username- > password- > security image- > OTP, ciò rende la creazione di un sito di phishing più complesso, anche se non ancora impossibile dal momento che il sito di phishing può emulare una sessione utente a il vero sito con username e password.

Le seguenti domande riguardano la diffusione di un accesso su più pagine in generale:

• Che cosa sono i vantaggi di un sistema di login a due pagine per una webapp?
• Accesso a due pagine per impedire l'esposizione accidentale della password

Il motivo per cui abbiamo deciso di non chiedere chiavi di autenticazione a due fattori allo stesso tempo non aveva nulla a che fare con la sicurezza. Si scopre che richiede una sola password nello stesso momento in cui il nome utente e la password normali possono causare errori di compilazione automatica con vari plugin, script e amp; i browser.

Questa è una ragione UX piuttosto che di sicurezza, ma abbastanza sostanziale da essere probabilmente la ragione di questo standard.

"Un modulo di accesso potrebbe rilevare un nome utente con l'autenticazione a 2 fattori abilitata" - Come?

Per fare ciò, la pagina dovrebbe inviare un'altra richiesta al server, incluso il nome utente (che sembra essere quello che stai cercando di evitare), o la pagina dovrebbe includere un elenco di tutti i nomi utente con autenticazione a 2 fattori abilitata nel corpo della pagina di accesso originale (non è una buona idea).

Ci sono vantaggi in questo caso specifico per mantenere se l'autenticazione a 2 fattori è abilitata a un segreto fino a quando la password non è stata inserita correttamente, in particolare nel caso di token inviati da un messaggio di testo, ad esempio. Se un 'baddy' riesce a trovare il nome utente e la password per il sito, potrebbe non sapere se l'autenticazione a 2 fattori è abilitata. Ciò significa che possono provare ad accedere e fare in modo che il servizio ti invii un messaggio, avvisandoti che la tua password è stata compromessa e impedendo loro di accedere al tuo account. Se riescono a capire immediatamente se il tuo account ha l'autenticazione a 2 fattori attivata, non corrono questo rischio.

Direi che si tratta di una limitazione del tipo di autenticazione utilizzata. Un sistema push, dial-back o basato su SMS (ad es .: Duo, PhoneFactor) è in realtà solo un fattore: il possesso del dispositivo, quindi l'utente deve anche inserire il qualcosa che conosci per primo, dando il via alla richiesta. Dal momento che ogni richiesta costa (sia a te che al servizio o entrambi) vogliono il minor numero possibile.

Altri sistemi includono entrambi i fattori in uno. Con Securid il PIN viene aggiunto all'OTP e inserito una volta. Con WiKID, il PIN viene inserito nel token per ottenere l'OTP, quindi è necessario inserire solo l'OTP.