Quanto è sicuro il mio sistema per la reimpostazione della password?

4

Sto usando il mio Parse Server personalizzato con Heroku che sono abbastanza sicuro (99%) che sia decentemente sicuro usando cose come oAuth2 e password hash a 1 via.

Il problema è che sto cercando di implementare la mia reimpostazione personalizzata della password .

Questo è quello che sto facendo attualmente:

  • L'utente richiede il ripristino della password

  • Viene generato un token personalizzato (ha un timer da eliminare dopo 10 minuti)

  • Viene inviata un'email con una richiesta POST http (s) per pubblicare l'id del token

  • La mia applicazione controlla se esiste l'id del token

  • Se true, l'utente viene reindirizzato a una pagina Web in cui è possibile reimpostare la password

  • L'utente fa clic su invia e la sua nuova password viene pubblicata utilizzando http (s) POST

  • Il mio server può quindi elaborare e impostare la nuova password in modo sicuro

Prima di tutto, si tratta di un problema che utilizza una richiesta iniziale di http (s) post con l'ID del token per richiedere una reimpostazione della password? So che se qualcuno si impossessasse di questo collegamento fisico mentre era attivo (entro 10 minuti) potrebbe cambiare la password di un utente, quindi accedere.

In secondo luogo, quando eseguo un'altra richiesta POST di http (s) con la nuova password utente, il metodo è sicuro e "sicuro" da questo metodo "decente"? Perché ancora una volta, se qualcuno potesse intercettare in qualche modo la richiesta, potrebbe ottenere l'accesso alla "nuova" password degli utenti?

La mia reimpostazione della password non deve essere perfetta, tuttavia voglio che sia una buona pratica.

C'è qualcosa di serio che sto sbagliando / facendo un errore e, in caso affermativo, cosa devo fare per risolverlo?

* Nota Uso "http (s)" con (s) tra parentesi perché non ho ancora portato un SSL.

Grazie.

    
posta Josh 28.04.2016 - 16:31
fonte

1 risposta

4

In generale, è sconsigliabile implementare la gestione della propria sessione. Se puoi, staresti meglio usando un'implementazione ben nota e collaudata.

Questi sono i problemi che vedo nella tua procedura.

L'utente richiede la reimpostazione della password

Come gestirai l'uso improprio di questa funzione: invierai una email per tentativo di reset o applicherai una restrizione per prevenire l'abuso?

Viene generato un token personalizzato (ha un timer da eliminare dopo 10 minuti)

Come genererai il token? Ci sono molti attacchi su numeri "casuali".

Che cosa succederà se il timer fallisce - il token della password di reset sarà valido per sempre? Che ne dici di archiviare la data di generazione e quindi consentire solo token "freschi"?

Viene inviata un'email con una richiesta POST http (s) per pubblicare l'id del token

Penso che un collegamento ordinario sia una scelta migliore qui. POST richiederà che i client di posta accetti i moduli html o javascript, il che più non lo è.

La mia applicazione controlla se esiste l'id del token. Se true, l'utente viene reindirizzato a una pagina Web in cui è possibile reimpostare la password

Dove si trova la pagina Web reindirizzata? Dovrebbe essere imprevedibile o richiedere il token della password di reimpostazione valido per evitare bypassare le vulnerabilità .

L'utente fa clic sull'invio e la sua nuova password viene pubblicata utilizzando il POST http (s) Il mio server può quindi elaborare e impostare la nuova password in modo sicuro

Sembra ragionevole

-

Ora, dovresti anche invalidare il token di reimpostazione della password. Non c'è bisogno di lasciarlo fluttuare se è stato usato.

E inutile dire che HTTPS è una buona idea.

    
risposta data 28.04.2016 - 16:52
fonte

Leggi altre domande sui tag