Guida per rivedere l'algoritmo 2FA

Dopo averlo pensato per 15 minuti e supponendo che sia implementato correttamente e che le applicazioni che lo utilizzano lo usino correttamente, l'unico problema minore che riesco a trovare è quello della lingua:

1.8 - the token is returned to the user UI (such as a mobile app or login website)

L'interfaccia utente implica che sia presentata all'utente. L'utente non ha bisogno di vedere il token, dovrebbe essere restituito all'utente client , che lo invia senza che l'utente debba vederlo. Questo è ovviamente un problema molto minore in quanto in realtà non danneggia nulla all'utente, non è proprio necessario.

Ovviamente, probabilmente vorresti qualcuno migliore di me a pensarci per più di 15 minuti.

Personalmente mi aspetto che una volta che una percentuale abbastanza significativa di persone utilizza 2FA (e abbastanza posti supportano 2FA), i phisher inizieranno a utilizzare proxy come Evilginx , a cui sono vulnerabili le soluzioni OTP. Per quanto ne so, l'unico metodo 2FA che ora impedisce questo è U2F, che richiede l'archiviazione di una chiave pubblica per ciascun utente.

Non credo che sia possibile possibile impedire questo tipo di phishing senza memorizzare una chiave pubblica, un segreto o qualcosa di simile per utente. Se implementassi 2FA, proverei a renderlo compatibile con U2F, o almeno a provare a progettarlo in modo che U2F o un metodo futuro possano essere facilmente aggiunti, se lo desideri.

Si noti inoltre che né gli SMS né le e-mail hanno forti garanzie di non essere intercettati. Almeno con TOPT o HOTP potresti usare qualcosa come Google Authenticator che, pur essendo ancora vulnerabile contro un proxy malevolo, almeno non deve inviare un codice che potrebbe essere intercettato.

Sembra "Non voglio camminare per un chilometro, quindi percorrerò invece cento chilometri" . Salvare sette numeri in un database, o un file piatto, o qualsiasi cosa è molto più semplice, e anche generico. La tua soluzione non è stateless, poiché lo stato viene inviato al client.

Non userò sicuramente il tuo sistema, è pieno di parti mobili. Se invierai un token all'utente tramite e-mail o SMS, salvalo e confrontalo in un secondo momento. È sufficiente un piccolo database SQLite e ci sono librerie per usarlo in quasi tutte le lingue. Avresti un database come questo:

[userid | token   | expiration         ]
|192    | 1234567 | 2018-07:15 10:11:12|
|723    | 7482912 | 2018-07:15 15:24:33|
----------------------------------------

Per evitare che il database diventi troppo grande, puoi eseguire un lavoro ogni ora circa per eliminare i token scaduti.

Puoi semplificare un po 'il sistema e liberarti del lavoro di pulizia utilizzando un TOTP appropriato. . Creare un database con l'ID utente e la chiave. Quando l'utente vuole autenticare, chiedi il token. L'utente aprirà Google Authenticator, Authy , 1Password , Enpass o qualsiasi altro client TOTP che utilizza. Quando l'utente invia il token, calcola e convalida il token. Sono disponibili anche molte librerie TOTP, per quasi tutte le lingue.

Per utilizzare il secondo approccio, aggiungerai alla tua applicazione solo un piccolo database SQLite e una libreria. Penso che il sovraccarico sia molto piccolo e semplifica molto il tuo processo.