Hai bisogno del tuo suggerimento su questo.
Considera che abbiamo un'applicazione mobile e un numero enorme di utenti. Vogliamo implementare la funzionalità di reimpostazione sicura della password con il consenso dell'esperienza utente.
Assunzione - Qui tutti noi crediamo che l'hacker abbia rubato il telefono della vittima, quindi l'implementazione tradizionale della reimpostazione della password non funzionerà come:
- Se inviamo la reimpostazione della password OTP sul telefono, l'hacker ha già il telefono della vittima. Quindi non usare.
- Se inviamo un token di reimpostazione della password, l'hacker ha il telefono della vittima dove, nella maggior parte dei casi, l'ID e-mail è collegato e aperto nel telefono. Quindi non usare.
Attuale implementazione - Se qualcuno richiede una richiesta di reimpostazione della password, diamo loro una nuova password dopo 24 ore. Manteniamo questa finestra temporale in modo che se il telefono dell'utente viene rubato e l'hacker invia una richiesta di reimpostazione della password, l'utente deve essere in grado di segnalarci entro 24 ore in modo che l'hacker non esegua attività dannose dal proprio account.
Problema - Abbiamo bisogno di ricostruire questa implementazione assumendo due cose in anticipo che il telefono dell'utente viene rubato e l'hacker ha inviato la richiesta di reimpostazione della password a noi e l'utente non ci ha segnalato che il suo telefono è stato rubato in 24 ore. Come possiamo identificare raggiungere questo compito senza identificare che l'utente sia legittimo o meno e l'account dell'utente è ancora sicuro?
Coppia di soluzioni:
- Iniziamo a fornire token hardware (token RSA, token VASCO) ai nostri utenti in modo che anche se il telefono viene rubato, per reimpostare e utilizzare la nuova password, l'hacker dovrà accedere fisicamente a questi token per accedere. (Problema: per noi è impossibile fornire 500000 token hardware per i nostri utenti.
- Numeri fidati - Durante la registrazione, l'utente aggiunge due numeri fidati che sono memorizzati nel nostro database. Con la richiesta di reimpostazione della password, forniamo la password in due distinti su quei numeri fidati e l'utente può accedere all'applicazione combinandoli. (Problema: l'esperienza utente diventa complicata e inaccettabile)
- Durante la registrazione forniamo alcune domande di sicurezza (non domande tradizionali sulla data di nascita, il nome da nubile della madre, ecc.) come selezionare 1 su 4 colori. Seleziona 1 su 5 cibo ecc. Durante la reimpostazione della password forniamo loro queste domande per rispondere come gli hacker non lo sapranno tutti. (Problema - Se mi registro ora e dimentico pin dopo 1 anno, non mi ricorderò di queste risposte, solo il caso in cui ricordo queste risposte è se ho preso uno screenshot di quelle risposte durante la registrazione che è di nuovo una preoccupazione nel telefono rubato )
- Codice di backup: forniamo codice di backup diverso da google durante la registrazione e l'utente dovrà aggiungerli per reimpostare la password. (Problema: la maggior parte dei casi, l'utente acquisisce screenshot di codici di backup o archivi nell'application notes che è di nuovo una preoccupazione nel telefono rubato)
Oltre a questi, abbiamo bisogno di altri suggerimenti attraverso i quali possiamo implementare soluzioni solide e l'esperienza utente continua a rimanere liscia.
Siamo completamente d'accordo sul fatto che la sicurezza e la complessità dell'utente siano inversamente proposizionali. Se vogliamo implementare la sicurezza a prova di proiettile, l'esperienza utente andrà male. Comunque voglio delle risposte dalla comunità se c'è un modo in cui possiamo farlo.
I suggerimenti sono apprezzati.