L'invio di password semplici su SSL come parte di un processo di aggiornamento della password è errato?

In realtà, direi che è meglio che UX cancelli i campi. Supponendo che i campi password siano pieni di asterischi, l'utente cancellerà comunque l'intero campo quando ridigitano la password.

Inoltre, ti stai aprendo a un nuovo rischio per la sicurezza. Ci sono possibilità per XSS, shoulder surfing e anche ogni volta che si inviano password ovunque tu abbia aumentato il rischio in generale.

Non ho mai visitato un sito che ha riempito i campi della password se ho inserito qualcosa di sbagliato. Il campo solo che è stato compilato era il campo email e probabilmente l'indirizzo / numero di telefono.

Devi sempre assumere il peggio, e se riesci a tappare un buco, fallo. Non penso che il revisore della sicurezza sia esagerato, soprattutto perché questa è una soluzione semplice per un problema UX davvero inesistente - e se stai rinviando le loro password e mostrandole senza cambiare ciascun carattere in un asterisco, allora sicuramente ha un problema di sicurezza. L'unica volta che qualcuno dovrebbe vedere una password che inseriscono è se selezionano un'opzione per consentire loro di vederlo temporaneamente.

È meglio avere una politica di password che viene solo immessa, mai emessa. Questo è un approccio pratico e un buon passo nella giusta direzione per la sicurezza con pochi costi.

Qualsiasi output di password sarebbe visibile anche in testo normale se si fa clic su "visualizza sorgente", il che significa che eventuali utenti esterni potrebbero visualizzare le password.

Se sta semplicemente chiedendo all'utente di reinserire la sua password originale, la nuova password e la conferma, questa non è una grossa lacuna dell'interfaccia utente. Se si tratta di una pagina enorme e la convalida su altri campi fa sì che le caselle della password non vengano visualizzate, può essere fastidioso per gli utenti reinserire le loro tre password ogni volta e può far sì che alcuni utenti inseriscano semplicemente qwerty o qualcosa del genere. In tal caso, spostarei i campi della password su un'altra pagina in modo che possano essere inseriti e convalidati separatamente.

Il riecheggiando l'input al client aumenta sempre il sospetto XSS di cross site scripting. Ma nel tuo caso, penso che sia una reazione eccessiva dal momento che l'output è transitorio e non verrà mai mostrato a nessun altro rispetto a chi lo ha inserito. Hai provato <script>alert(document.cookie);</script> come password?

Potresti giocare con il tuo auditor modificando l'intera password e chiamando l'Ajax da solo, non cancellando mai il modulo né modificando la pagina. Avresti bisogno solo di rispondere con un codice di errore regolare di conseguenza l'interfaccia utente. Un po 'come questo:

1. Richiedi la password corrente, nuova e ripubblicata in un modulo
2. L'utente fa clic su "Cambia password", viene effettuata una richiesta Ajax sul server. Il modulo rimane, con qualche gif-in-a-div animato per far aspettare l'utente
3. Se la modifica non riesce, il server risponde con un codice di errore (non abbastanza complesso, nuovo e ripetizione non corrispondono, ecc.)
4. Se non corrispondono, cancella sia il campo nuovo che quello ripetuto

Ricorda che la vecchia password sta invecchiando con ogni tentativo fallito. La vecchia password è lì per garantire che l'utente legittimo stia apportando la modifica. Più la riutilizzi, più debole diventa quella certezza. È necessario cancellare tutto dopo N tentativi falliti (o dopo N secondi).

Credo che il motivo per cui è considerato insicuro inviare le password al client è perché il client può memorizzare nella cache la pagina, il che significa che c'è una versione della password in testo semplice memorizzata da qualche parte sull'unità locale dell'utente. Premendo il pulsante Indietro o analizzando la cache potrebbe rivelare la password. Questo è particolarmente negativo sulle macchine pubbliche.

Inoltre, ci sono scenari validi in cui potresti voler fare ciò che l'OP sta suggerendo. Ad esempio, se si dispone di una schermata di registrazione con un captcha su di esso, con l'utente ridigitare due password ogni volta che falliscono il captcha potrebbe essere eccessivamente fastidioso. Tuttavia, se il tuo sito è abbastanza importante da richiedere un controllo di sicurezza, probabilmente stai meglio evitarlo e prendere in considerazione la possibilità di semplificare il captcha.

Non penso che reinserire le tre password sia un'esperienza utente scadente, ti preghiamo di preferirlo ed evitare di inviarle di nuovo!

Immagina che l'utente abbia lasciato il computer e qualcun altro faccia qualcosa come console.log($('#oldpassword').val()); Che male.

Mentre puoi vedere solo i punti nei campi delle password, se dimentichi l'ultimo carattere, in genere cancelli tutto il campo, quindi reinserisci nuovamente l'intera password.

Poiché le comunicazioni SSL sono difficili da decifrare, cosa viene trasferito tra i nodi? Ti dà una sensazione di freddo sul collo, sapendo che i tuoi dati sensibili sono in giro e nessuno lo controlla.

quindi Se stai cancellando la password sul lato server, continua a farlo !! non lasciare vincere Vaddin. e dal lato client, eliminare sempre i dati sensibili.