Informazioni su Dimenticate l'implementazione della sicurezza della password

3

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.

    
posta FrOgY 03.06.2017 - 06:29
fonte

4 risposte

1

Il mio suggerimento è di passare il tempo ai grandi: buttare fuori la tua implementazione personalizzata e usare qualcosa come OAuth per far accedere i tuoi utenti con google o facebook - proprio come StackExchange !

Se devi mantenere le stesse cose: perché pensi che le reimpostazioni della password siano sempre dovute agli hacker? Hai misurato il motivo per cui si verifica il ripristino della password? Scommetto che molti di loro sono dovuti agli utenti che si dimenticano semplicemente delle loro password (cioè penso che tu stia iniziando con ipotesi sbagliate e stai per degradare l'esperienza per la maggior parte degli utenti, proteggendo solo una piccola percentuale di utenti).

    
risposta data 03.06.2017 - 06:47
fonte
1

I token hardware sono costosi e spesso costosi. Come decisione aziendale, può essere possibile chiedere all'utente di sostenere il costo (fornire un elenco di token compatibili e qualsiasi fase di inizializzazione), rendendolo quindi un'opzione percorribile sia dal punto di vista dei costi che della logistica.

Anche i numeri di fiducia sono fallibili (gli utenti dimenticano di aggiornare le informazioni di contatto recenti) Si potrebbe ricordare agli utenti di confermare i loro numeri recenti di tanto in tanto (pop-up come Google / Twitter / altri ... "È ancora il tuo numero di backup ? "). Potresti semplicemente notificare l'utente sia al numero principale sia a quello secondario / indirizzo e-mail, coprendo così il rischio di perdita della copertura di un dispositivo / numero / indirizzo e-mail. Penso che chiedere conferma dal numero alt / indirizzo sia una barriera troppo grande per essere efficace per la sicurezza.

Domande di sicurezza, codici di backup: sono i meno desiderabili per le ragioni che hai indicato tu stesso.

La chiave qui è usare un auth-factor che è improbabile che venga memorizzato (e quindi perso con) il dispositivo. Hai bisogno di approfondire la tua conoscenza / relazione con i tuoi clienti per identificare questo. ad esempio, alcune banche richiedono che venga inviato un documento di prova di indirizzo fisico per le richieste di modifica dell'indirizzo. Il back office lo verifica.

Dei tre fattori standard (quello che sai, quello che hai e quello che sei), solo il primo sembra utile in questo scenario. Non deve essere una informazione statica (come la data di nascita), o informazioni facilmente disponibili (qualcosa sul profilo FB).

Una possibilità: chiedere la quantità approssimativa di (o il nome di un negozio di) una transazione recente per andare avanti. O quando è stato effettuato l'ultimo pagamento. Qualcosa del genere che l'app / BackEnd avrebbe saputo e l'utente non lo dimenticherà facilmente, ma non all'esterno del sistema.

    
risposta data 03.06.2017 - 08:00
fonte
1

Penso che la soluzione migliore siano le opzioni 3 e 4.

Domanda di sicurezza

Non sono un grande fan delle domande sulla sicurezza. Personalmente, non ricordo mai quali risposte ho dato a questi. Tralascia giustamente il nome da nubile della madre e la data di nascita come troppo facili. Il tuo suggerimento di scegliere tra cibi, colori, ecc. Non è una cattiva idea in generale: c'è una ricerca che afferma che le preferenze delle persone sono abbastanza stabili nel tempo, così che se scelgono un determinato cibo ora, la probabilità che scelgano la stessa immagine di cibo in due anni è alta, anche se non ricordano esattamente la loro scelta. Il problema con l'idea è che scegliere uno su cinque dà ad un attaccante che non sa nulla di un'alta probabilità di successo con scelte casuali delle immagini, anche se si concatenano tre di queste domande (1 su 125, che è banale - se si hanno 500000 clienti , un determinato aggressore potrebbe riuscire a penetrare in circa 5000 account del tuo cliente). E con ogni ulteriore domanda, le probabilità che un client legittimo risponda ad una di esse aumenta in modo errato.

Potresti anche avere domande di sicurezza che aprono un gran numero di possibilità, la cui risposta è stabile, come "le ultime quattro cifre del numero di licenza del tuo conducente" e "il numero ISBN del tuo libro preferito" e così via sopra. A seconda di quante possibilità si aprono, dovrai anche consentire all'utente di rispondere a due o tre di queste (le ultime quattro cifre del numero di licenza del tuo conducente apriranno solo 10000 possibilità, il che significa che con 500000 client, 50 di i loro account saranno compromessi da un determinato aggressore anche se effettua un solo tentativo per cliente).

Codice di backup

Potresti fornire questo codice QR che può essere stampato e archiviato da qualche parte. Idealmente, se hai un indirizzo postale per i tuoi clienti, puoi inviarlo tramite posta ordinaria. Questo sarebbe molto più economico di un dispositivo di sicurezza hardware (ma comporta ancora costi per spedire una lettera).

Recupero password posta elettronica

In effetti, se in realtà hai un indirizzo postale per i tuoi clienti, puoi semplicemente eseguire il recupero della password tramite posta ordinaria.

Non ignorare le soluzioni che riguardano il possesso del telefono

Si presume che un utente malintenzionato che ruba il telefono del cliente ottenga automaticamente l'accesso a qualsiasi sistema di ripristino configurato per il telefono. Anche se questo potrebbe essere per lo più vero in teoria, direi che in pratica i telefoni non vengono rubati principalmente al fine di ottenere l'accesso all'identità digitale di qualcuno. Molto probabilmente, un ladro di telefono non sarà interessato ai dati che si trovano sul telefono (a parte forse guardando la galleria di immagini). Quindi se rendi il possesso del telefono una parte del tuo sistema di recupero, questo aggiunge sicurezza per la maggior parte dei client.

    
risposta data 03.06.2017 - 14:06
fonte
0

possiamo fare una cosa qui, Ogni volta che effettuo il login con l'applicazione posso navigare su quell'applicazione solo come utente ospite (non con accesso completo) ya posso vedere tutti gli aggiornamenti tutte le nuove offerte di notifiche ecc., Posso vedere tutte le mie cose e tutte, bene ora se Voglio fare una transazione O voglio trasferire denaro O ottenere soldi nel mio portafoglio O voglio cambiare i miei dettagli, Quindi per quella prima, ho bisogno di accedere con il mio account, e dopo ho bisogno di generare OTP no. e dopo, ho bisogno di rispondere alla domanda di sicurezza (che è stata usata nel tempo di registrazione). quindi questa è la sicurezza a tre vie. e al termine della transizione, mi disconnetto automaticamente.

ancora lo stesso processo continua ..

    
risposta data 03.06.2017 - 13:30
fonte

Leggi altre domande sui tag