2009-07-01 10 views
13

Qual è la tua opinione sull'invio del nome utente e della password al loro indirizzo e-mail quando si registrano sul nostro sito ... in questo modo se dimenticano la password in futuro, possono guardate nella loro e-mail ... anche noi non dovremo impiantare lo scenario di dimenticanza/reset password (siamo vicini al rilascio) ..invio di nome utente e password tramite e-mail dopo la registrazione dell'utente nell'applicazione Web

è questo approccio abbastanza sicuro?

  1. mia seconda domanda è che, in fondo sul nostro sito, l'utente compila certe forme e inserire alcune informazioni come il loro nome, indirizzo, numero di telefono, informazioni sul reddito e tali informazioni personali .. alla fine, quando inviano l'applicazione, stiamo pensando di inviarli via e-mail un riassunto di tutte queste informazioni come il loro nome, indirizzo ecc in modo da averlo per i loro record ..

è questo ok..safe abbastanza .. quali sono le preoccupazioni

+3

solo un pensiero probabilmente non degno della sua propria risposta qui sotto ... Hai pensato di usare OpenID? Ti consente di superare molti problemi di sicurezza che riguardano la registrazione e le password dell'account, poiché non tocchi mai realmente la password dell'utente e non è tua responsabilità cambiarla se dimentica. – rmeador

+0

Potrebbe non rispondere alla domanda, ma vale sicuramente la pena menzionarla. Se il tuo pubblico è tecnicamente abbastanza esperto da capire OpenID, usalo. –

+0

concordato. Mi piace la soluzione OpenID. – jinsungy

risposta

2

La preoccupazione è sicuramente nell'invio della mail con la password. Se non è crittografato correttamente, qualcuno potrebbe potenzialmente annusare i pacchetti dall'e-mail inviata e recuperare la password. Inoltre, la persona potrebbe potenzialmente avere un account email dirottato. Se non è un grosso problema se qualcuno ruba la password, allora non dovresti preoccuparti, ma altrimenti NON invierei alcuna password non criptata via email.

Modifica: per rispondere alla tua seconda domanda, non invierò nemmeno un'email. Vorrei invece inviare un link in modo che possano facilmente vedere il loro profilo/informazioni quando accedono.

1

La maggior parte delle aziende semplicemente non include la combinazione di password Nome utente a causa della sicurezza del client di posta esterno. Qualsiasi numero di utenti potrebbe forzare la forza o indovinare la password per l'account e-mail di un altro utente che consentirebbe all'hacker di visualizzare l'e-mail del proprio sito. Quindi l'hacker potrebbe devastare il tuo sito pure

1

Direi che fornire una funzione di password dimenticata sarà comunque vitale in quanto non tutti saranno garantiti a tenere tutte le e-mail (o addirittura a trovarli in seguito). ..

4

La mia regola generale sarebbe: se stai scrivendo su una cartolina e inviandola per posta, allora è OK per l'e-mail standard. Non credo che le informazioni sul reddito rientrerebbero in quella categoria per la maggior parte delle persone.

Per quanto riguarda le password, se non riescono a ricordarle in primo luogo, non saranno in grado di trovare l'e-mail con la quale sono state inviate con la password, ed è un'ammissione di memorizzarle in chiaro. Lo eviterei e darei loro i mezzi per resettare - ne avranno comunque bisogno.

23

Non inviare mai una password o altre informazioni sensibili in chiaro. Questo include l'e-mail. Si dovrebbe anche memorizzare il meno possibile in un formato recuperabile. La comunicazione non crittografata, in particolare la posta elettronica, è facilmente manomessa e non si desidera che le persone sbagliate ricevano le password.

Se possibile:

  • Conservare le password in un hash salata, in modo che il testo originale è irreversibile, e quindi inscindibile da qualche cosa di meno che un attacco di forza bruta. Se l'utente dimentica la propria password, falla resettare e invia una password temporanea (che è richiesta da modificare all'accesso) o un link di conferma (che, di nuovo, richiede una nuova password) via e-mail.

  • Non inviare mai dati sensibili tramite e-mail; se l'utente ha bisogno di informazioni, falli andare sul tuo sito per ottenerlo. Stai usando HTTPS, giusto?

+2

Si dice di non inviare mai una password in chiaro, ma si suggerisce di inviare una password temporanea via e-mail. e-mail == insicuro. – jinsungy

+1

Da qui l'obbligo di cambiarlo al momento dell'accesso. Il ripristino della propria password via e-mail non è sicuro a prescindere da come lo si fa (una password temporanea o un URL); la speranza è che qualsiasi informazione trasmessa nel processo sia obsoleta dal momento in cui un utente malintenzionato può raggiungerla. L'unica vera alternativa è il meccanismo della domanda segreta, che può essere fatto su un protocollo sicuro, ma pone domande che la maggior parte degli aspiranti attaccanti potrebbe semplicemente cercare, rendendola così meno sicura della posta elettronica. –

+1

"la speranza è che qualsiasi informazione trasmessa nel processo sia obsoleta" E se l'utente non controlla la sua posta elettronica per una settimana?Che ci crediate o no, questo succede. Un utente malintenzionato può facilmente ottenere la password temporanea. L'unica cosa nell'email per l'utente dovrebbe essere "la tua email è stata resettata". – jinsungy

4

Spesso le persone condividono le password attraverso i siti. Quindi dovresti assumere che la stessa password funzioni per l'online banking del cliente, e non dovresti mai inviarla via e-mail o fornire un modo (per qualcuno che finge di essere) al cliente di recuperarlo.

Va bene inviare loro un'e-mail di conferma con il loro nome utente - questo è utile.

Ricordare che se si invia loro la password tramite e-mail è probabile che si dimentichino di tale e-mail o semplicemente di eliminarla. Quindi è necessario un altro meccanismo di reimpostazione della password.

Il modo migliore per gestire il caso "password dimenticata" è che l'utente richieda all'utente di inviare tramite e-mail all'utente un collegamento; quando fanno clic sul collegamento, consentono loro di digitare una nuova password.

Per quanto riguarda le informazioni personali (indirizzo, reddito, ecc.): perché qualcuno vorrebbe questo inviato a loro? Lo sanno già! Stai solo inviando dati privati ​​non crittografati su Internet senza motivo.

2

Dico alla gente di pensare all'e-mail come una cartolina: un dipendente di un'azienda che lo gestisce tra il mittente e il destinatario può leggerlo.

2

Quando si inviano informazioni via e-mail, non sarà sicuro. Ci sono troppi modi in cui qualcuno può averlo. Sarebbe un gioco da ragazzi per un hacker esperto che cerca di rubare le tue informazioni.

Astenersi dall'inviare le informazioni personali come le password e le informazioni sul reddito via e-mail in quanto può diventare MOLTO EMBARRASSANTE per te e la tua organizzazione se tali informazioni sono trapelate o rubate. Pensa seriamente alla sicurezza. Basta un incidente per far cadere tutti i mattoni.

Come per il recupero della password, leggere attentamente Forgot Password Best Practices.

La linea di fondo è che un'applicazione seguendo le migliori pratiche dovrebbe consentire ad un utente di reimpostare la propria password. Le domande di sicurezza personale devono essere utilizzate. L'applicazione non deve inviare email , visualizzare password e non impostare alcuna password temporanea .

EDIT: collegamento aggiornato ...

+0

Si presume che il sito sia protetto con SSL! – jinsungy

+0

E che le risposte alle domande non siano facilmente indovinate o cercate. Il nome da nubile di mia madre, ad esempio, è di dominio pubblico. –

+0

È logico che avere una domanda di sicurezza non sia sufficiente, specialmente qualcosa come il nome da nubile della madre. Utilizza più domande di sicurezza non deboli. – jinsungy

0

Ho tre norme in materia di password:

  • Non memorizzare le password in testo normale nel database
    • Perché dovrebbe le persone si fidano di te con quel tipo di informazioni? Potresti avere solo buone intenzioni, ma le grandi aziende hanno fallito prima, quindi anche tu sei a rischio.
  • Non utilizzare password di promemoria
  • offrono sempre di inviare una nuova password via email
    • Questo è il modo più sicuro di recuperare le password. È necessario forzare l'utente a modificare la password una volta effettuato l'accesso con la nuova password.
+1

Il punto 3 è soggetto agli attacchi DoS. Invia sempre collegamenti che ti consentano di reimpostare una password, non resettarla immediatamente. – molf

0

Come accennato nei commenti, si potrebbe desiderare di guardare OpenID. Il modo più sicuro per gestire le password è eliminarle.

1

sono d'accordo con la risposta superiore e avere questo per aggiungere: ogni volta che ricevo una mail di conferma di iscrizione che contiene la password elimino l'e-mail e fortemente considero mai usando ancora una volta che il servizio web. Per me, indica una mancanza di sicurezza per la privacy &.

0

ho creare un'applicazione Web per inviare informazioni riservate tramite email. Non è perfetto per l'interfaccia utente, ma è davvero sicuro e funziona molto bene.

Ci

un plugin prospettiva, API per collegare sito esterno e il sito web.

Il concetto è il messaggio ricevuto nella tua casella di posta non sono in chiaro. È un'e-mail HTML con un link. È necessario fare clic sul collegamento per accedere al contenuto dell'e-mail. Quando accede una volta, il messaggio viene distrutto.

Il messaggio sono magazzino in un database criptato dalla nostra parte. È possibile configurare una password che solo le due parti conoscono per aprire il messaggio online o ricevere una password (numero Random 6) via SMS.

'molto semplice da implementare dall'API.

C'è un campione

// https://www.secure-exchanges.com/API.aspx

var nom = this.Nom.Value; 
      var prenom = this.PrenomNom.Value; ; 
      var email = this.MotPasse.Value; 
      string sujet = string.Format("Informations pour {0}, {1} courriel :", prenom, nom, email); 
      API.APISoapClient secure = new API.APISoapClient(); 
      Guid user = Guid.Empty; 
      Guid psw = Guid.Empty; 
      string serialNumber = "xxxxxxxxxxxxxxx"; 
      Guid.TryParse("xxxxxxxxxxxxxxxx8", out user); 
      Guid.TryParse("xxxxxxxxxxxxxxxxxxx", out psw); 
      API.GranttKeyAnswer a = secure.GetAccessToken(user, psw); 

      API.SendMessageAnswer a2 = secure.SendMessage(user, a.GranttAccessKey, "mon message", "", sujet, true, "[email protected]", false, "819-888-8888", serialNumber, "onlyEmail", "fr-CA"); 
Problemi correlati