E 'possibile inviare all'utente una password generata casualmente mentre la si conserva ancora nel database?

Quindi, dopo una conversazione in chat con @forest, sono arrivato a la risposta / conferma che stavo cercando. Essenzialmente, si , è possibile fare qualcosa di simile a quello che stavo chiedendo, ma sarebbe davvero sicuro se anche il metodo di trasmissione fosse sicuro.

If they sent it [the password] via a medium as secure as the password submission form, it would be fine. If a one-time password were used, there would be a window for attack if the OTP were sent over an insecure medium, but it wouldn't be nearly as severe.

L'idea migliore qui, per evitare di memorizzare la password, è avere una chiave K che solo il tuo server conosce. Quindi quando un utente si iscrive, si crea un collegamento come: signup.php username = xxxx &? [email protected]& password = randomrandom & scadenza = nnnnnnnnnn & hash = (*)

(*) quindi consistono in sha256 (K + ":" + [email protected] + ":" + xxxx + ":" + randomrandom + ":" + nnnnnnnnnn)

Usando questo metodo, non è necessario memorizzare nulla. Quando l'utente si registra, l'unica cosa che succede è che il link sopra è generato e inviato, nulla è memorizzato nel database.

Quando si fa clic sul collegamento, l'account viene creato per davvero. (Ovviamente, è necessario ricontrollare che il nome utente non sia stato preso e che l'e-mail non sia già registrata, ad esempio)

Ciò garantisce che nulla debba essere memorizzato fino a quando l'azione non è stata completata completamente dall'utente.

Puoi anche avere questo link sopra per creare direttamente & accedi all'utente (senza alcuna password casuale iniziale) e chiedi all'utente di selezionare una password alla prima visita.

Quindi, se ignoriamo l'insicurezza della posta elettronica, allora stai dicendo:

1. L'utente si iscrive
2. Il servizio genera la password
3. Servizio Sali, hash e memorizza la password
4. La sicurezza del servizio invia la password all'utente con un metodo non specificato

Beh, sì, è meglio essere sicuri dato che alcuni servizi oggi lo fanno, anche se la maggior parte lascia che l'utente specifichi una password.

Per quanto riguarda la protezione dell'e-mail della password, quello che vuoi fare è avere una parte che condivide un segreto con una seconda parte senza avere un modo offline di pre-condividere un segreto. L'unico modo in cui sono consapevole di trasferire in modo sicuro i dati tra due parti che non comunicano in modo interattivo tra loro e che non dispongono di un segreto precondiviso, è la crittografia a chiave pubblica. Quindi, se hai avuto modo di generare una coppia di chiavi pubblica / privata e hai specificato la tua chiave pubblica quando ti sei registrato per il servizio, il servizio potrebbe crittografare la tua password usando la tua chiave pubblica e potresti decifrare con la tua chiave privata quando ricevuto l'email.

I am not asking about the security of transmitting the password, just about if there is a good way for the service to keep it secure on their end while still being able to send the user their password in the clear.

Bene, se sei a tuo agio con loro, chiunque li hacker, qualsiasi dipendente canaglia e probabilmente qualsiasi servizio segreto in qualunque paese operi in possesso dell'accesso alla tua password, senza una buona ragione, solo perché ti fidi di loro , quindi è perfettamente sicuro!

Non c'è una buona ragione perché ci sono soluzioni per la memorizzazione delle password che non devono memorizzare la tua password effettiva. Vedi questa domanda: Come fare in modo sicuro le password di hash?

Forse potrebbe esserci un caso d'uso per essere in grado di recuperare una password in chiaro, ma in cima alla mia testa, non posso pensare a nessuno, soprattutto per questa applicazione (un servizio VPN). Non vedo la necessità di archiviarlo in modo recuperabile.

Se i trasgressori del testo in chiaro sono corretti è fuori portata qui, non sto dicendo nulla al riguardo. Ma se memorizzano la tua password in chiaro, allora è semplicemente stupido. Non riesco a pensare a nessuna giustificazione.

Quindi è sicuro? Sì, a condizione che non vengano violati, nessuno dei loro dipendenti si inasprisce e non riceve alcuna infamosa lettera di sicurezza nazionale (o equivalente del loro paese). Non sono sicuro di voler scommettere su questo.