È una cattiva pratica far sapere all'utente la sua password con hash?

Sembra un'esposizione inutile per me. Si spera che non sia solo un hash, ma con un considerevole salario per utente casuale e un KDF con molte iterazioni. Anche così, l'intento del design è di mantenerlo protetto sul server, non di inviarlo ai client.

Se come dici tu, il campo nascosto viene inviato dal server solo dopo l'autenticazione corretta, il rischio è di gran lunga minore (in modo un hacker non sarebbe facilmente in grado di raccogliere hash tentando di resettare un sacco di password degli utenti), ma sembra ancora inutile.

Il motivo per cui stiamo ancora parlando del rischio è che i sistemi e le reti degli utenti finali sono molto più facili da indagare, rispetto ai server protetti in modo consapevole. Quindi, se in questo caso un attaccante ha una posizione privilegiata su una rete che utilizza il protocollo SSL strippaggio a suo perimetro, poi (s) che non avrebbe bisogno di "hackerare il server" -. Aggirando così le protezioni sul lato server

Potremmo sostenere che "l'account utente verrà comunque cancellato", e in una certa misura sarebbe vero (rischio inferiore). Tuttavia, una cache di password utilizzate (se possono essere derivate dagli hash) è piacevole da avere - dal momento che il riutilizzo della password è dilagante.

Come hai descritto sopra, questa è una cattiva pratica probabilmente . Il tuo browser web non dovrebbe aver bisogno di conservare la tua password (o la tua password con hash) dopo la prima autenticazione. L'approccio standard prevede l'utilizzo dell'autenticazione basata su token , in cui l'autenticazione viene effettuata una sola volta e il server restituisce un token di autenticazione alla macchina che non include l'account o la password in in qualsiasi modo.

link

In questo caso il vantaggio principale è che la password o il suo hash non è in giro più del necessario. Il server dovrebbe restituire un token al computer che ti autorizza a eliminare il tuo account dopo aver completato il secondo modulo.