Domanda:
L'invio della password all'email dell'utente è sicuro?
user310291
2012-08-01 15:18:51 UTC
view on stackexchange narkive permalink

Quanto è sicuro l'invio di password tramite posta elettronica a un utente, poiché la posta elettronica non è protetta da HTTPS.

Qual è il modo migliore per proteggerla? Devo usare la crittografia?

No, no, no, no no! Non usare mai password in testo normale nelle e-mail. Infatti non inviare mai password, se possibile.
Vale la pena leggere questo post sul blog di Troy Hunt su Tesco, il principale supermercato del Regno Unito, che invia password tramite e-mail. http://www.troyhunt.com/2012/07/lessons-in-website-security-anti.html
No, mai. Ci vergogniamo persino di coloro che lo fanno su plaintextoffenders.com.
@SimonWhitaker È divertente che tu lo abbia pubblicato: sono stato molto coinvolto nella campagna per convincerli a risolverlo! :)
Il fatto che tu possa inviare agli utenti la loro password significa che stai memorizzando la password dell'utente in testo normale o almeno in un codice reversibile. Questo da solo è motivo di bandiera rossa.
@user606723 Come fanno tutte le banche a chiedere le lettere x, yez alle password se non stanno facendo cose strane con esse o non le crittografano affatto. Certamente non hash di sale + pass ...
Le banche @ewanm89: sono i principali autori di reato quando si tratta di sicurezza. Detto questo, è possibile che la domanda implichi l'invio di una password temporanea all'utente come misura di ripristino. Molti siti lo fanno, quindi ti costringono a modificarlo non appena effettui l'accesso.
In teoria, le banche @ewanm89 potrebbero almeno immagazzinare hash di ogni combinazione di caratteri che chiederanno.
Oltre a ciò che altri hanno detto, tieni presente che la posta elettronica può essere crittografata in rete (HTTPS non è l'unico protocollo crittografato di uso comune là fuori!). Il mio server di posta è impostato per eseguire la crittografia opportunistica "STARTTLS" su SMTP, e il server POP non ti consente nemmeno di accedere a meno che non avvii prima una sessione TLS. Tuttavia, questo non riguarda l'archiviazione.
@ewanm89 In realtà, le sfide della "parola segreta" come quella sono solitamente implementate in un modulo HSM black-box, quindi dovresti compromettere fisicamente il dispositivo per romperle.
@MichaelKjörling "_Il mio server di posta è configurato per eseguire la crittografia STARTTLS opportunistica su SMTP_" controlli il certificato TLS? Contro cosa?
@MichaelKjörling e lo richiedi per tutta la posta inviata e ricevuta ad altri server ... E i server attraverso cui viene inoltrata la posta, puoi garantirli?
I certificati @curiousguy vengono confrontati con il set di certificati CA fornito con l'implementazione SSL del sistema operativo.
@ewanm89 È impostato per eseguire la crittografia ** opportunistica **; non richiedere TLS. La richiesta di TLS per il semplice traffico SMTP a ogni server casuale su Internet si interromperà troppo, ma a chiunque lo chieda viene detto che il supporto STARTTLS è disponibile su ESMTP e viene utilizzato occasionalmente sia per il traffico in entrata che in uscita. E * ovviamente * non posso garantire nulla su come sono configurati altri server di posta. Posso solo assumermi la responsabilità del mio piccolo angolo di Internet. Se voglio una sicurezza end-to-end, utilizzo GnuPG.
@MichaelKjörling "_Se voglio una sicurezza end-to-end, utilizzo GnuPG._" PGP / GPG e TLS su SMTP hanno scopi diversi e proteggono cose diverse. Nessuno dei due è superiore, né sostitutivo dell'altro.
@MichaelKjörling "_I certificati vengono verificati rispetto al set di certificati CA fornito con l'implementazione SSL del sistema operativo._" il certificato deve nominare il dominio dell'indirizzo email di destinazione?
@curiousguy "* PGP / GPG e TLS su SMTP hanno ambiti diversi e proteggono cose diverse. *" Questo è il mio punto. "* il certificato deve nominare il dominio dell'indirizzo email di destinazione? *" No, perché un server con un certificato può potenzialmente gestire la posta elettronica per molti domini. Anche se il server sapesse in qualche modo quale certificato presentare, una singola transazione SMTP può comportare la consegna a destinatari su domini diversi sullo stesso server, quindi non avrebbe alcun modo di sapere quale certificato presentare in anticipo. ** Comunque ** questo va molto lontano dalla domanda come chiesto.
Una volta ho trovato un webhoster che richiedeva una password abbastanza sicura ... molto lunga (credo almeno 12 caratteri), numeri, caratteri speciali e così via ... Innanzitutto ho pensato che fosse sicura. Quindi l'hanno inviato in chiaro. Non ho più ospitato il mio sito web lì.
@LieRyan: Quello che ho visto è la password * reset *, in cui il sistema genera una * nuova * password, la invia all'utente, quindi l'ha hash e memorizza l'hash nel database. Il passaggio "email" è ancora insicuro come qualsiasi email, ma almeno questa sequenza non richiede l'archiviazione reversibile della password.
Anche se l'e-mail fosse protetta da una connessione https, non sarebbe comunque sicuro inviare una password. La posta elettronica viene archiviata in testo normale a meno che non sia crittografata. Ciò significa che una volta che il client ha scaricato i dati non è sicuro. se parliamo di un client web, in teoria anche la cache è vulnerabile, dipende molto dal client. Non entrerò nelle differenze o nella mancanza di differenze tra SMTP e HTTP, HTTPS, versioni crittografate protette di SMTP.
Cinque risposte:
Polynomial
2012-08-01 15:33:25 UTC
view on stackexchange narkive permalink

Non dovresti mai inviare password in chiaro, né archiviarle in chiaro. Dovresti eseguire l'hashing utilizzando un hash crittografico unidirezionale lento come bcrypt o PBKDF2. Se un utente dimentica la password, gli offri una funzione di "reimpostazione della password", che invia un link di reimpostazione una tantum al suo account.

Uno schema come il seguente è ragionevole:

  • Hash tutte le password usando a salt più bcrypt / PBKDF2 . Vedi il mio ragionamento qui. (EDIT, marzo 2019: usa Argon2)
  • Convalida gli hash al momento del login.
  • Se un utente dimentica la password, inviagli una copia sicura link di ripristino, utilizzando un token di ripristino generato in modo casuale memorizzato nel database. Il token deve essere univoco e segreto, quindi sottoponi a hash il token nel database e confrontalo quando viene utilizzato il collegamento.
  • Imponi che un token possa essere utilizzato solo per reimpostare la password dell'utente che lo ha richiesto.
  • Una volta che il token viene utilizzato, deve essere eliminato dal database e non deve essere consentito di essere riutilizzato.
  • Tutti i token equivalenti a una password, inclusi i token di ripristino, scadono dopo un breve periodo, ad es 48 ore. Ciò impedisce a un utente malintenzionato di sfruttare i token inutilizzati in un secondo momento.
  • Visualizza immediatamente un modulo per consentire all'utente di impostare una nuova password. Non utilizzare password temporanee generate casualmente!
  • Fai tutto questo su SSL.

Consiglio vivamente di leggere la Guida definitiva all'autenticazione del sito basata su moduli per una serie completa di linee guida su come creare sistemi di accesso sicuri.

+1 Il problema principale non ha nulla a che fare con la posta elettronica. Il problema principale è che le password vengono archiviate in testo normale o con crittografia reversibile. Risolvi il problema e la domanda e-mail si risponde da sola.
Non c'è niente di sbagliato nell'inviare una password monouso in chiaro. Ad esempio, il sistema ha appena creato / ripristinato un account per te, la tua password iniziale è qualcosa di creato casualmente (`sA2aXUpHcYrm`), valido per 1 giorno, e al primo accesso ti verrà chiesto di impostare la tua password. È ancora necessario valutare la sicurezza di questa funzionalità poiché la creazione di account / reimpostazione della password è spesso un anello debole nei protocolli di sicurezza.
@drjimbob in effetti non è diventato diverso da un collegamento di ripristino, senza l'autologin e la parte dell'account selezionata.
"Se un utente dimentica la password, inviagli un link di reimpostazione una tantum sicuro, utilizzando un token di reimpostazione generato casualmente e archiviato nel database. Il token deve essere univoco e segreto, quindi hash il token nel database e confrontalo quando il collegamento si usa." Non è diverso dall'invio di una password temporanea. Potrebbe anche essere meno sicuro a meno che il browser dell'utente non crittografi automaticamente le richieste HTTP (cough Internet Explorer cough). Almeno con una password temporanea, puoi essere certo che verrà inviata tramite HTTPS, mentre con un token incorporato in una richiesta GET, non puoi.
@Wug Non puoi revocare una password temporanea con la stessa facilità, dopo un periodo di tempo prestabilito. Inoltre confonde gli utenti, poiché avranno un accesso non riuscito nonostante l'e-mail che dice che la nuova password è valida. Inoltre, un collegamento di ripristino obbliga l'utente a modificare immediatamente la password, riducendo il rischio che la password temporanea venga rubata in un secondo momento. Inoltre, non capisco il tuo argomento HTTPS: perché un link come "https: //example.com/reset? Token = 123 ..." fa sì che il token venga inviato in chiaro quando si accede?
Il token fa parte della richiesta HTTP, non del payload dei dati. Se usassi POST probabilmente andrebbe bene, ma alla maggior parte dei client di posta elettronica non piacerà. Se hai mai usato socket sicuri in java, noterai che c'è un flag che deve essere impostato esplicitamente per crittografare gli argomenti HTTP, altrimenti verranno inviati in chiaro anche su HTTPS. Non so se IE si comporti in questo modo o no, ma conoscendo i suoi difetti passati, non sarei disposto a fare alcuna scommessa.
@Wug Ehm, penso che tu abbia frainteso HTTPS. L'intera conversazione HTTP, inclusi i parametri GET, sono tutti incapsulati all'interno del flusso SSL. Prendi una copia di Wireshark e verificalo tu stesso.
Inoltre, sarebbe abbastanza facile da fare, basta tenere traccia sia dell'hash della password che di un timestamp di scadenza della password nelle informazioni utente. Invia loro la password e archivia il suo hash nel database con una scadenza di 24 ore. Se non la usano, la password scade e devono richiedere un altro reset, se lo fanno, gli fa cambiare la password (che riporta anche il tempo di scadenza al valore predefinito presumibilmente infinito).
Proverò quando torno a casa come i browser lo trattano, ma sono abbastanza sicuro che i parametri potrebbero non essere crittografati (c'era un exploit di Minecraft qualche tempo fa che comportava l'annusare la password dalla richiesta di sessione, che è stata inviata come HTTPS a un server di accesso che restituisce un token di sessione protetto, ma gli argomenti GET sono stati inviati in testo normale).
@Wug Questo è ancora complicato. Inoltre, un token completamente casuale è * più forte * di una password, poiché ha `2 ^ n` bit di entropia, dove` n` è la lunghezza del token in bit. Confrontalo con una password, che ha un'entropia molto più difficile da calcolare, e basta dire che sarà un numero inferiore. Per quanto riguarda l'exploit di Minecraft, sono abbastanza sicuro che fosse dovuto al dirottamento della sessione standard, ovvero la schermata di accesso era HTTPS, ma le richieste successive erano semplici HTTP, che perdeva l'ID di sessione.
Perché il token dovrebbe essere cancellato dal database dopo l'uso? A rigor di termini, è sufficiente non consentirne l'uso di nuovo.
L'intero URL della richiesta è crittografato in HTTPS; questo è il motivo per cui i domini protetti devono essere ospitati su indirizzi IP dedicati, poiché la selezione del certificato non può essere basata sull'indirizzo della richiesta poiché tali informazioni non sono disponibili per il server fino a * dopo * che la sessione è stata negoziata. Anche così, se il token è utilizzabile una sola volta, quale sarebbe il danno se fosse inviato in chiaro? Nel momento in cui chiunque potrebbe averlo osservato, non funzionerà più.
@AndreyBotalov Qual è il punto di tenerlo nel database se non può mai essere utilizzato di nuovo?
@AndreyBotalov: Abbastanza vero, eliminarlo è un dettaglio di implementazione, ma sembra la cosa più pratica da fare (quale sarebbe lo scopo nel mantenerlo?) Piuttosto che aggiungere logica per determinare se il token è valido o meno.
Perché hash il token nel DB? Da quale attacco protegge?
@chiborg Se un utente malintenzionato viola il database, potrebbe utilizzare i token di ripristino per ottenere l'accesso a qualsiasi account desideri. L'hashing dei token lo impedisce, poiché non può determinare quale fosse il token originale.
Penso che sia importante indicare il motivo di tutti i meccanismi di protezione con password: è per proteggere le password degli utenti poiché comunemente usano la stessa password su più siti. Se il tuo sistema è compromesso, non dovrebbe compromettere le password degli utenti.
@SarelBotha Non solo. È importante impedire all'autore dell'attacco di accedere al sistema utilizzando i dati acquisiti dal database.
@AdamRobinson È interessante notare che conserviamo i token di ripristino, ma li contrassegniamo con una data "dichiarata" in quanto ci consente di controllare il processo dopo il fatto.
So che ci sono alcuni siti che, quando ti registri, genererà una password iniziale casuale e te la invierà per e-mail, poi effettui il login e ti costringe a cambiarla.Non sembra così male (ad esempio, potresti inviarlo non appena lo generi e non archiviarlo mai come testo normale nel tuo DB), ma è comunque una cattiva idea, giusto?
@Kevin Il problema è che se l'utente non effettua il login, ti rimane un account che utilizza una password che potrebbe essere nota a un utente malintenzionato.Diventa anche una condizione di competizione se usano una rete non attendibile.Se non si desidera richiedere una password prima della verifica, dovrebbe esserci un collegamento di attivazione del timeout di 24 ore / 48 ore per l'account, quindi l'utente dovrebbe essere costretto a inserire una password per la prima volta al momento dell'attivazione.
@Phil non è necessario memorizzare una password per inviarlo.Puoi inviare l'email con la password nel momento in cui viene generata o inviata dall'utente.E fondamentalmente è archiviato, ma è archiviato sul lato utente, non si memorizza l'email.
@maciejkrawczyk Puoi, ma stai comunque trasmettendo la password tramite un protocollo non sicuro (email).
Thomas Pornin
2012-08-01 16:31:01 UTC
view on stackexchange narkive permalink

L'email non è sicura. L'invio di una password tramite e-mail è quindi un rischio per la sicurezza. Per mitigare il rischio, è possibile (in alcune situazioni) fare in modo che la password inviata tramite e-mail sia una password monouso, che sblocca solo la possibilità per l'utente di selezionare una nuova password di proprio.

Questo è ciò che fanno i buoni sistemi Ho-dimenticato-la-password-per-questo-sito: l'utente fa clic sul pulsante "dannazione, ho dimenticato la mia password" e viene inviata un'e-mail, che contiene un URL ( con HTTPS) che incorpora un identificatore di sessione casuale e punta a una pagina che consente all'utente di scegliere una nuova password. L'URL è la "password monouso". Con questo schema, puoi almeno, dal lato server, sapere quando è stato utilizzato l'URL.

Se puoi eseguire la crittografia correttamente , cioè se puoi inviare un OpenPGP o Messaggio S / MIME crittografato con la chiave pubblica dell'utente, quindi l'utente dispone di una coppia di chiavi privata / pubblica: in tal caso, perché dovresti usare le password?

Quindi cosa impedisce al collegamento nell'e-mail di essere dirottato da un intermediario che utilizza il collegamento per reimpostare la password dell'utente?
user10211
2012-08-01 15:26:52 UTC
view on stackexchange narkive permalink

È una cattiva pratica inviare password all'utente, poiché ciò significherebbe che si dispone di una copia in chiaro della password dell'utente.

Non riesco a pensare a nessuna buona ragione per farlo. Esistono altri modi più sicuri per realizzare ciò che è necessario.

Per una risposta generale sulla sicurezza della posta elettronica, ti consiglio di leggere questo link, che contiene alcune buone informazioni.

Se DEVI inviare informazioni sensibili tramite posta elettronica, utilizzare uno schema come PGP o altre tecniche di crittografia per proteggere i dati.

Questo non è vero; è possibile creare una e-mail da inviare all'utente dopo l'invio per creare la password. Ad un certo punto nel tempo, avrai sempre la password in chiaro. Anche se sono d'accordo che non sia intelligente inviare le password per posta elettronica dopo aver creato un account, ciò non significa che manchi l'archiviazione della password. Puoi memorizzare la password con PBKDF2 SHA-512 con 10k itterazioni, questo non significa che non puoi inviare la password scelta dall'utente tramite e-mail.
@NKCSS: un giorno qualcuno registrerà un account sul tuo sito web, utilizzando la propria posta di lavoro condivisa, con la propria password personale.
@NKCSS Vero, potresti inviare la password immediatamente prima di archiviarla e la tua soluzione * di archiviazione * potrebbe essere sicura. Ma l'invio della password in chiaro è ancora incredibilmente insicuro. Senza preoccuparsi della possibilità che Lie Ryan ha suggerito, dovresti anche preoccuparti di chi potrebbe ascoltare la conversazione e-mail. L'utente potrebbe utilizzare un servizio che trasferisce le e-mail in chiaro tra i server o al client. Vedere la mia risposta su [questo argomento] (http://security.stackexchange.com/a/13222/953) per ulteriori motivi per non fidarsi della riservatezza della posta elettronica.
Vaughan Hilts
2012-08-02 02:58:28 UTC
view on stackexchange narkive permalink

Se hai la "password chiara" da inviare in primo luogo (a parte il processo di registrazione), stai sbagliando. Mai e poi mai memorizzare la password in chiaro! Molte aziende come Sony Music e simili sono state bruciate ultimamente da questo .. e lasciate che vi dica che i consumatori non sono contenti.

Per essere chiari (gioco di parole non inteso), non dovresti * mai * inviare la password in chiaro, nemmeno durante la registrazione. Sì, per natura del processo, probabilmente avrai una copia in chiaro (o crittografata) della password durante la registrazione, ma dovrebbe essere immediatamente salata, sottoposta ad hashing e archiviata nel database * secure *, mai inviata o mostrata all'utente.
Katie Campbell
2012-08-01 18:13:18 UTC
view on stackexchange narkive permalink

Facendo eco ai post precedenti, le email non sono certamente sicure e non dovresti mai inviare dati sensibili , in particolare password. Soprattutto dal momento che non sono crittografati e si trovano in un testo in chiaro, è estremamente facile per chiunque hackerare la tua posta elettronica e ottenere l'accesso a questi attraverso la rete pubblica.

Se tu o il tuo cliente avete problemi a ricordare le vostre password, dovreste utilizzare un gestore di password sicuro. Questo è un sito Web che ospita un elenco delle tue password in un deposito completamente crittografato. Quelli buoni sono KeePass o LastPass.

Se sei un'azienda che sta tentando di inviare di nuovo la password ai clienti, dovresti impostare delle domande di sicurezza a cui i clienti rispondono quando creano inizialmente il loro account. In questo modo, se lo dimenticano, possono fare clic su un collegamento che li invia per rispondere correttamente a queste domande e reimpostare la password.

Per tua conoscenza, questo è un blog informativo, che sostiene la crittografia e mette in guardia contro l'uso di determinate password http://www.ziptr.com/blog-last-4-digits -ssn-password da Ziptr.

FYI: KeePass non è un "sito web". È un'applicazione. E, per impostazione predefinita, non si sincronizza con il cloud. Tuttavia, credo che siano disponibili plug-in per sincronizzarlo con DropBox o altri servizi di archiviazione cloud.


ⓘ
Questa domanda e risposta è stata tradotta automaticamente dalla lingua inglese. Il contenuto originale è disponibile su stackexchange, che ringraziamo per la licenza cc by-sa 3.0 con cui è distribuito.
Loading...