Quando l'invio del modulo fallisce, il campo della password viene oscurato, perché è così?

Buona domanda. Avendo il vantaggio di guardare alcune delle risposte e di rifletterci io stesso, in realtà non vedo alcun vantaggio di major dalla cancellazione della password dal modulo parziale restituito all'utente, ma sicuramente sono alcuni rischi da prendere in considerazione.

Da un punto di vista della architettura della sicurezza (come già toccato @Roryalsop), di solito vuoi che le password scorrano solo in una direzione. Dall'utente all'applicazione, mai indietro. Questo vale per tutti i livelli e questo sistema a senso unico offre vantaggi dal punto di vista della sicurezza. Avere un'eccezione a questa regola potrebbe o potrebbe non essere una buona idea. Ma è per questo che la tua domanda è interessante. Questo scenario merita un'eccezione?

Osserviamo alcuni vettori di attacco e vediamo se il nullo della password protegge da qualcuno di questi:

• sniffing the traffic - se un utente malintenzionato è in grado di intercettare le comunicazioni tra l'utente e il server, può annusare la password inviata in primo luogo dall'utente. Non vedo alcun vantaggio nello svuotarlo sulla risposta
• malware sul lato server o client - lo stesso. Può intercettare la password iniziale.
• dati memorizzati nella cache - questo è stato già citato brevemente da @SachinKumar ma vale la pena espandersi. C'è una maggiore possibilità che se il server restituisce la password con la risposta, potrebbe finire in cache da qualche parte (il server memcached, un server proxy lungo il percorso, la cronologia del browser del client, ecc). Le richieste del cliente non vengono mai memorizzate nella cache. Le risposte del server sono! Questo è probabilmente il più grande rischio che vedo. I proxy possono essere probabilmente eliminati dall'equazione utilizzando SSL e, se il server utilizza le intestazioni della cache corrette e imposta correttamente il campo di input, questo può anche attenuare il caching del browser. Detto questo, è ancora possibile che il valore venga memorizzato in cache da qualche parte, anche accidentalmente e probabilmente non è auspicabile.

Tuttavia, azzerare la password è abbastanza semplice, non dovrebbe danneggiare troppo l'esperienza dell'utente e mantenere le cose pulite da un punto di vista della sicurezza. Ti suggerisco comunque di continuare a farlo.

Se sei preoccupato per l'esperienza utente, prova a segui i consigli che ti erano già stati dati su UX - esegui validazione extra da parte del cliente, solo così l'utente ottiene un feedback tempestivo. Non sostituire la convalida sul server. Questa è la convalida più importante alla fine. Ma per il feedback degli utenti, la convalida sul lato client può fare miracoli per migliorare l'esperienza dell'utente e non è necessario prendere neppure un leggero rischio che la password venga memorizzata nella cache (o modificare l'architettura di sicurezza facendo un'eccezione).

Why is it insecure to post back the same pass that user has entered?

Perché se si visualizza la fonte sulla pagina posteriore pubblicata, la password sarà visibile in testo normale. Ciò va contro il principio secondo cui le password dovrebbero essere unidirezionali, vale a dire che le password possono essere immesse ma non emesse mai. Ad esempio, quando si memorizzano le password nel database, queste devono essere sottoposte a hash anziché crittografate per impedire che vengano estratte se un utente malintenzionato riesce a visualizzare i dati. Seguendo questo principio ovunque si otterrà un sistema più sicuro.

In questo caso può impedire la "spartitraffico" e può proteggerlo dal fatto che venga memorizzato nella cache dal browser e successivamente visualizzato.

È possibile avere una buona interfaccia utente e seguire questo principio. Ad esempio, il sistema potrebbe memorizzare la password hash e salata nello stato di sessione lato server, quindi sul modulo di ritorno il modulo mostra solo gli altri campi. Una volta che questo ha superato la convalida, viene utilizzata la password dallo stato di sessione piuttosto che da quella che il modulo avrebbe fornito. Naturalmente, è necessario prestare attenzione qui per invalidare la sessione se l'utente non continua con il processo di registrazione in modo che questa password non sovrascriva quella impostata dal visitatore successivo da quel browser. altrimenti potrebbe essere possibile un attacco per la sessione .

2 punti chiave qui:

1. Se hai un meccanismo per rinviare la password all'utente, offri a un utente malintenzionato un modo per ottenere quella password.
2. Se puoi inviare la password all'utente, vuol dire che non stai memorizzando l'hash, ma usando il clear text o la crittografia reversibile. tuttavia come sottolinea @yoav, in questo particolare scenario IT non è ancora stato crittografato, quindi questo punto è irrilevante qui.

Entrambi hanno dei rischi.

Questo è il motivo per cui la maggior parte dei siti web ha meccanismi di promemoria e di reset della password, quindi non è necessario inviarti la password. Potrebbero inviarti una password monouso come reset, che dovrai quindi modificare.

Alcuni invieranno la tua password in un percorso fuori banda, ma questi diventano sempre più rari a mano a mano che i rischi continuano a crescere.

(ovviamente la sicurezza dei meccanismi di reset della password è un'altra questione)