Un altro vettore di attacco da considerare è Session Hijacking. Supponendo che stai usando Post-Redirect-Get (che dovresti essere in generale), dovresti salvare la password nella sessione per poterla inviare di nuovo via GET. Mentre la sessione si trova in un luogo attendibile e relativamente sicuro (sul tuo server), la memorizzazione di testo normale o password crittografate in modo reversibile consente alla tua sessione di memorizzare un obiettivo ancora più grande. Ma diciamo che è quello che fai.
Supponiamo che un utente malintenzionato ottenga o elabora la variabile di sessione dell'utente. L'utente inserisce la password ma fallisce il modulo. Chiunque emetta una richiesta GET con quella variabile di sessione (che potrebbe essere l'autore dell'attacco) riceve la password in chiaro. Questo è peggio di un dirottamento di sessione standard, perché un dirottamento standard consentirebbe solo all'utente malintenzionato di impersonare l'utente, non ottenere password che potrebbero essere valide per altri siti.
Naturalmente, puoi mitigarlo con le difese di dirottamento di sessioni standard: la rigenerazione del token al caricamento o semplicemente il rendering su post invece di evitare completamente la sessione. (Per favore, non farlo, avere il browser che mi disturba quando riaprio o ricarico una pagina è frustrante, soprattutto perché lo faccio molto grazie al non-script.)
Meno posti la password esiste, meno bersagli per l'attacco. Se devi fare questa funzione, o vai con il suggerimento di commento di Andre per rimuovere completamente il campo della password con un pulsante per cambiarlo, o riempire il campo della password con una password standard, ma non valida (cioè inferiore alla tua lunghezza minima) che puoi controlla per quando hai memorizzato una password. Basta non inviare password reali, anche su HTTPS.