Gestione della funzionalità "password dimenticata" con dati crittografati senza domande di sicurezza

13

Come una sorta di follow-up di questo domanda sulla gestione della funzionalità di reimpostazione della password quando si gestiscono dati utente crittografati, esiste un buon metodo per reimpostare la password di un utente in un'applicazione Web crittografata senza utilizzando domande di sicurezza?

Dal punto di vista della sicurezza, il problema si riduce alla necessità di una seconda chiave per sbloccare i dati nel caso in cui il primo (la password) vada perso, lasciando:

  1. Domande di sicurezza

    • Preferirei non implementarli a causa di problemi di sicurezza e di esperienza dell'utente (nella mia esperienza, le domande saranno così oscure che l'utente probabilmente non le ricorderà, o le risposte saranno pubblicamente- informazioni disponibili, sconfiggendo l'intero scopo)

    • Questo è sicuramente l'approccio con cui la maggior parte degli utenti avrebbe familiarità e sarà quello che implementerò se non trovo altre buone soluzioni

  2. Una chiave di backup

    • Un esempio è la "chiave di ripristino" di Apple, che dovresti stampare quando abiliti l'autenticazione a due fattori per il tuo ID Apple

    • Questo è un passaggio aggiuntivo che gli utenti non prenderanno, o prenderanno e in seguito perdono la loro chiave di ripristino, portando a confusione e ad una scarsa esperienza utente

    • Altre possibilità includono un'app sul dispositivo mobile dell'utente che memorizza una seconda chiave fino a quando è necessaria, ma mi sembra eccessivo, e probabilmente un passo che gli utenti dimenticheranno, portando l'app a non essere più -installati quando ricevono un nuovo telefono, ad esempio

  3. Alcuni moduli di deposito di chiavi

    • Il mio primo pensiero è stato quello di consentire agli utenti di connettere un account esterno con OpenID Connect, ma nessuno dei provider comuni (Google o Facebook, ad esempio) restituisce alcun tipo di valore unico, stabile e segreto che sarebbe utile come una seconda chiave nell'account (la cosa più vicina a Google è un identificatore univoco dell'account, che riceverà ogni sito che richiede l'accesso al proprio account Google)

Ci sono delle opzioni che ho trascurato qui, o qualche soluzione intelligente a cui chiunque possa pensare che non implichi domande di sicurezza?

EDIT: per chiarire, per questa specifica applicazione, è un requisito che io (o qualsiasi altro sviluppatore o amministratore del sistema) non abbia accesso a nessuno dei dati non crittografati, in qualsiasi momento. Ciò significa che metodi come l'invio di un codice monouso non saranno sufficienti, in quanto richiede che, ad un certo punto, abbia accesso alla chiave per decrittografare i dati. (Questa restrizione esclude la breve quantità di tempo in cui la chiave è in memoria quando l'utente la invia per decrittografare i propri dati. Sono più preoccupato per la decrittografia offline di un dump dei dati di quanto l'applicazione stessa sia stata compromessa in caso di perdita / archiviazione tasti)

    
posta MPLewis 27.03.2016 - 01:08
fonte

1 risposta

1

Sono d'accordo con te sul problema delle domande di sicurezza.

Che ne dici di avere gli utenti che ti danno il loro numero di cellulare come backup in modo da poter poi inviare loro un codice one time, che inseriranno per dimostrare che sono chi dicono di essere? In realtà è come Yahoo fa questo ora. Puoi creare un account gratuito lì (o probabilmente ne hai già uno) e testare questa funzionalità.

L'unico problema è che richiede agli utenti di avere telefoni cellulari. Tuttavia, hai già menzionato i telefoni cellulari nella tua soluzione Key Escrow, quindi immagino che i tuoi utenti si aspettino di averli.

    
risposta data 29.03.2016 - 21:52
fonte

Leggi altre domande sui tag