Perché è pericoloso inviare a un utente la propria password tramite la comunicazione crittografata SSL anziché inviare sempre un link di ripristino?

Tre enormi problemi con questo:

• Il server deve essere in grado di inviare la password, il che significa che il server conosce la password, il che significa che anche l'amministratore / proprietario del server può leggerlo. Questo dovrebbe mai essere possibile (vedi molti argomenti su hash, sali e funzioni di derivazione multipla). Mentre un amministratore con tutti gli accessi al server può già impersonare gli utenti ecc. Come desiderato, molti utenti usano la loro password per più cose. L'amministratore non dovrebbe essere in grado di accedere a questi.
• Se il server viene violato, lo stesso è valido per l'utente malintenzionato: non dovrebbero essere in grado di leggere le password, perché non dovrebbero essere in grado di riutilizzarle in altri luoghi.
• E no, SSL non è "completamente sicuro". Soprattutto, TLS esiste perché SSL è piuttosto insicuro (ma TLS non è perfetto neanche).

Un problema importante non è stato ancora menzionato:
L'autenticazione (mancante) del client in SSL / TLS .

Mentre @deviantfan ha alcuni punti validi, vorrei aggiungere questo problema di base, perché la tua proposta non è fattibile.

TLS senza autenticazione client:

In genere SSL / TLS vengono eseguiti con il server che si autenticano sul client, ma non viceversa. Ciò significa che qualsiasi client può configurare una connessione TLS sicura con il server e assicurarsi che il server sia legittimo. Tuttavia, se non c'è l'autenticazione del client, il server non può essere sicuro, se la persona che si connette ad esso è la persona che afferma di essere. Pertanto, non avrebbe senso che il server invii una password a qualsiasi client in questa configurazione.

TLS con autenticazione client:

Nel caso in cui l'autenticazione del client venga effettivamente eseguita per configurare la sessione TLS, il server può essere sicuro che il client è chi afferma di essere. Tuttavia, per abilitare l'autenticazione del client, sul lato client è necessario installare un certificato (+ chiave privata). Se questo tipo di autenticazione reciproca è già stato stabilito, non sarebbe necessario avere una password per accedere in primo luogo.

Generalmente i server non memorizzano la password, invece memorizzano l'hash della password insieme a un 'sale'. Il sale è un dato casuale che viene utilizzato come input aggiuntivo per la funzione unidirezionale che blocca la password.

L'aggiunta di sale e l'hashing della password lo impediranno da attacchi di dizionario o attacchi da tavolo arcobaleno pre-calcolati.

Le risposte fornite sono abbastanza chiare. Tuttavia, da un punto di vista logico, devo sottolineare che dicendo:

" when you'd probably prefer to keep it the same, you just forgot it."

non è possibile. Poiché i siti considerati sicuri non conoscono nemmeno la tua password e solo l'utente che lo conosce, se l'utente dimentica completamente la password, significa che è persa ... per sempre.

In secondo luogo, se hai dimenticato la tua password, è una buona indicazione che hai scelto una password per soddisfare l'algoritmo di immissione della password piuttosto che una password valida per tu l'utente. Gran parte della colpa è di solito dal lato dei progettisti del sito, dal momento che non dovrebbero tentare di proteggere l'utente da se stesso (costringendo con forza a scegliere una password "strong") e invece dovrebbero potenziare il loro gioco e lavorare su tecniche migliori di protezione della password. A tale proposito, il sito ti sta sottilmente dicendo che "hey, hai scelto una password errata, ecco la tua possibilità di ottenere una migliore, più facile da ricordare."