Re-display password nel modulo di registrazione buono o cattivo?

6

Quando un utente tenta di registrarsi e i dati che invia non sono corretti, come e-mail cattiva o password debole, visualizzeremo di nuovo la pagina di registrazione con i dati che ha appena inviato insieme ai messaggi di errore.

La mia domanda è: dovremmo mostrare la password che ha appena inviato in HTML?

<input type="password" value="s0me7Xpwd">

O lascia semplicemente vuoto e lo infastidisce per inserirne un altro?

È decisamente meglio nell'esperienza utente inserire nuovamente la password (specialmente quando la password è a posto), ma sarebbe utile per quanto riguarda la sicurezza?

    
posta datasn.io 18.04.2015 - 11:42
fonte

1 risposta

2

Questo non è un problema in sé, ma a mio parere un'applicazione web dovrebbe implementare la politica che le password sono solo input, mai output. Seguire questa politica si tradurrà in un sistema molto più sicuro per quanto riguarda la gestione delle password.

Se hai intenzione di farlo, assicurati di impostare le intestazioni appropriate per impedire la memorizzazione nella cache nel browser o in qualsiasi server proxy lungo il percorso:

Cache-Control: private, no-cache, no-store, max-age=0, no-transform
Pragma: no-cache
Expires: 0

Si noti che la password sarà ancora visibile se si fa clic su Vista sorgente nel browser dell'utente. Questo è un rischio aggiuntivo, anche se molto basso, poiché un utente normale è improbabile che lo faccia. L'unica volta in cui potrei pensare che la password possa "scappare" in questo modo è se l'utente decide di salvare la pagina HTML localmente usando la funzionalità della pagina di salvataggio del browser.

È possibile memorizzare la password in sessione dopo averla convalidata rispetto a qualsiasi criterio dei requisiti password e corrisponde alla conferma. Quindi potresti semplicemente includere del codice per sopprimere l'output dei campi della password se la password è già stata accettata dalla tua applicazione. Lo svantaggio di questo approccio è che le password sono conservate in memoria più a lungo di quanto non sia altrimenti necessario, il che significa che la tua applicazione ha un rischio leggermente più elevato di attacchi alla memoria. Heartbleed è stato uno - ovviamente hai bisogno della vulnerabilità di esistere in primo luogo per il rischio che l'esposizione aumenti in questo modo . Un modo per mitigare questo è cancellare la password ASAP e memorizzare l'hash e il sale in memoria.

Se desideri consentire all'utente di modificare la password, puoi generare un campo con un "valore magico" anziché con la stessa password.

<input type="password" value="notrealpassword">

Quindi si rileva semplicemente se l'utente modifica successivamente questo campo per sapere se aggiornare la password memorizzata nella sessione.

    
risposta data 21.04.2015 - 11:55
fonte

Leggi altre domande sui tag