Invio della password generata dal server tramite e-mail

Sì, molte cose. Mentre questo è sfortunatamente procdure standard, è una cattiva idea:

• Queste password dovrebbero essere invalidate dopo un breve periodo di tempo (e specialmente se le e-mail non sono crittografate end-to-end).

  Ci sono buone probabilità, anche qualcun altro ha quelle password, perché le email sono cartoline piuttosto che lettere .

  Se le password vengono invalidate così velocemente, la maggior parte degli utenti potrebbe non essere abbastanza veloce per inserirle da sé.

• Se il tuo sito web non è TLS fino in fondo (o qualcosa va a sud, tramite XSS o malware), c'è anche una buona possibilità che un utente maltrattato possa dirottare la sessione e accedere anche alla password (se inviata senza essere notata).

  Questo è particolarmente vero per il WiFi gratuito, non crittografato, dato che molti utenti controllano le loro e-mail non crittografate, esponendo subito la password. Un approccio automatico sarebbe sempre più veloce dell'utente.

Un approccio migliore sarebbe utilizzare un TOTP con un secondo fattore (come un'app per smartphone o un token di sicurezza. Esistono app per questo per tutti i principali smartphone ( Google Authenticator che sono grandi, ma altre app può essere utilizzato anche) e token di sicurezza non sono quasi nulla in fase di acquisto.

Se questa non è un'opzione, prova a ricorrere a un altro canale di comunicazione fuori banda, come SMS o chiamate vocali automatizzate, leggendo la password ad alta voce e invalidandola 10 secondi dopo.

Nota a margine:

and it seems that the issue isn't with sending passwords, but storing plaintext passwords.

Non è corretto, ci sono diversi problemi e rischi con entrambi.

it seems that the issue isn't with sending passwords, but storing plaintext passwords.

No, il problema riguarda davvero l'invio di password.

La loro memorizzazione in testo semplice è un problema diverso (i due possono verificarsi contemporaneamente allo stesso tempo).

Se si inviano password tramite e-mail, l'accesso all'e-mail dell'utente significa l'accesso alla password (ad esempio, acquisita tramite forza bruta, se un utente non si disconnette, ecc.). Significa anche che chiunque si trovi tra il client di posta elettronica degli utenti e il tuo server di posta potrebbe essere in grado di accedere alla password.

Ecco perché l'approccio raccomandato è un token una tantum. L'accesso all'e-mail significa ancora accesso al token, ma è qualcosa che può essere registrato e l'utente può essere informato a riguardo, il che riduce i rischi.

A seconda della tua situazione specifica, devi decidere se i rischi di esporre una password secondaria sono abbastanza alti da ripensare il tuo approccio o se sei disposto a correre questo rischio.

Si tratta di una password monouso connessa solo a una particolare transazione? In tal caso, la soluzione è piuttosto sicura (ed è simile alla soluzione utilizzata da molte banche - utilizzando il codice PIN monouso inviato tramite un messaggio di testo (SMS) per l'autorizzazione delle transazioni).

Invia una password via email non è considerato sicuro.

Ci sono diversi problemi con l'invio di password via email:

• L'email viaggia in testo normale su Internet. Di conseguenza, un Man-in-the-middle potrebbe intercettare l'e-mail contenente la password. (un attacco MitM è un thread molto reale, ancora di più con l'ampia prevalenza di punti wifi pubblici).
• L'email è probabilmente archiviata (per un lungo periodo di tempo) nella posta in arrivo dell'utente. Quindi, c'è una copia di testo in chiaro della password, in forma recuperabile, in archivio per vedere chi ha accesso alla posta in arrivo degli utenti (ad esempio, un collega che raggiunge un picco su una workstation non presidiata)

Se ti invii solo una password "una tantum" via email, la pratica è considerata abbastanza sicura.

(Oltre a questo problema, dovresti, mai memorizzare la password in testo semplice)