L'email è un canale sicuro di comunicazione?

[microbo87]

Sto realizzando un sito e servirà anche registrarsi su questo sito. Pensavo di comunicare una password generata in automatico, tramite email, senza lasciare all'utente la possibilità di cambiarla.

Infatti quando l'utente scrive la password e viene inviata, anche se con un algoritmo tipo MD5, c'è il problema che l'utente può scegliere una password banale. Inoltre, viene inviato tramite metodo POST con una form HTML e potrebbe essere intercettato. Per esempio un "uomo nel mezzo", anche senza risalire alla password, potrebbe manipolare i messaggi.

Invece, l'email dovrebbe essere un canale sicuro perché usa una connessione HTTPS. Però, ho letto su un forum di utenti che si lamentavano con un amministratore di un servizio hosting perché questi inviavano dati di connessione (utente e password) tramite email in chiaro.

Pensavo che la risposta sarebbe stata: l'email è un canale di comunicazione sicuro. Invece la risposta è stata: "è per una questione di comodità, gli utenti sono facilitati, poi ognuno dovrebbe andare a cambiare password e metterne una personale".

Un'altra lamentela è che questi utenti (clienti) erano quasi scandalizzati perché il server conosceva le loro password (dato che erano inviate in chiaro) e non si usava un HASH. Ma anche questa lamentela mi sembra sciocca, perché comunque del server (insomma chi lo amministra) ti devi fidare. Con o senza password possono vedere tutti i dati salvati, non gli serve proprio la password.

Semmai dovrebbe il browser (client) criptare i dati, così nemmeno quelli del server possono leggerli e la password non viene MAI inviata (resta sempre in mano all'utente). Ma un caso del genere, si può avere solo quando serve fare storage di dati, non nei normali siti web. Infatti, i singoli utenti potrebbero leggere solo i loro stessi dati, tanto vale lasciarli sul proprio pc o al massimo hanno solo bisogno di uno storage online.

Insomma, del server bisogna fidarsi. Lasciare la password in chiaro sul server e comunicarla in chiaro per email, che è un canale sicuro (chi non utilizza HTTPS??), mi pare una pratica del tutto serena e usare HASH o non inviare password per email, ma PEGGIO con metodo POST in una form HTML: o non aggiunge nulla alla sicurezza, o addirittura la peggiora.

Lo so che poi per l'autenticazione si deve ad ogni pagina richiesta inviare la password tramite cookie o variabili di sessione, però c'è uno stratagemma che usa numeri casuali e criptazione e decriptazione per far sì che client e server comunichino in modo del tutto sicuro, senza più HTTPS che però è necessaria la prima volta, quando con l'email viene inviata la password che solo server e utente conosceranno e non si comunicherranno mai più, nemmeno con HASH.

Gradirei molto avere il parere di qualche esperto. Grazie tantissimo!

[Habanero]

Originariamente inviato da microbo87
Sto realizzando un sito e servirà anche registrarsi su questo sito. Pensavo di comunicare una password generata in automatico, tramite email, senza lasciare all'utente la possibilità di cambiarla.

Infatti quando l'utente scrive la password e viene inviata, anche se con un algoritmo tipo MD5, c'è il problema che l'utente può scegliere una password banale. Inoltre, viene inviato tramite metodo POST con una form HTML e potrebbe essere intercettato. Per esempio un "uomo nel mezzo", anche senza risalire alla password, potrebbe manipolare i messaggi.

Sinceramente... impedire all'utente di cambiare password non mi sembra una buona idea. Se un minimo conosci i servizi offerti su internet noterai che nessuno adotta questa politica.
Premesso che l'unico modo decentemente sicuro per far viaggiare delle credenziali di autenticazione sia usare HTTPs... è vero anche che di solito questo è un servizio a pagamento e che se il servizio offerto non è critico di solito si rinuncia alla connessione criptata.

Invece, l'email dovrebbe essere un canale sicuro perché usa una connessione HTTPS. Però, ho letto su un forum di utenti che si lamentavano con un amministratore di un servizio hosting perché questi inviavano dati di connessione (utente e password) tramite email in chiaro.

Pensavo che la risposta sarebbe stata: l'email è un canale di comunicazione sicuro. Invece la risposta è stata: "è per una questione di comodità, gli utenti sono facilitati, poi ognuno dovrebbe andare a cambiare password e metterne una personale".

L'email NON è un canale sicuro, sicuramente non più degli altri. A meno che l'utente che scarica la posta non usi connessioni SSL/TLS o STARTTLS, tutti i dati (contenuto + autenticazione) passano sulla rete in modo non criptato e come tali sono ancora soggetti a intercettazione

Un'altra lamentela è che questi utenti (clienti) erano quasi scandalizzati perché il server conosceva le loro password (dato che erano inviate in chiaro) e non si usava un HASH. Ma anche questa lamentela mi sembra sciocca, perché comunque del server (insomma chi lo amministra) ti devi fidare. Con o senza password possono vedere tutti i dati salvati, non gli serve proprio la password.

Le password non vengono memorizzate sotto forma di hash per impedire che gli amministratori possano accedere alle aree utenti ma piuttosto per impedire che nal caso il server venga violato il pirata di turno non abbia accesso a tutte le password degli iscritti al sito... Le password su DB DEVONO essere memorizzate come hash. In ogni caso, considerando che molti utenti scelgono password uguali per molti diversi servizi, è bene che le password non siano accessibili nemmeno agli amministratori.

Semmai dovrebbe il browser (client) criptare i dati, così nemmeno quelli del server possono leggerli e la password non viene MAI inviata (resta sempre in mano all'utente). Ma un caso del genere, si può avere solo quando serve fare storage di dati, non nei normali siti web. Infatti, i singoli utenti potrebbero leggere solo i loro stessi dati, tanto vale lasciarli sul proprio pc o al massimo hanno solo bisogno di uno storage online.

Questa cosa non mi è per nulla chiara... che c'entra lo storage dei dati?
Dati critici o credenziali di autenticazione dovrebbe sempre girare su HTTPS.

Insomma, del server bisogna fidarsi. Lasciare la password in chiaro sul server e comunicarla in chiaro per email, che è un canale sicuro (chi non utilizza HTTPS??), mi pare una pratica del tutto serena e usare HASH o non inviare password per email, ma PEGGIO con metodo POST in una form HTML: o non aggiunge nulla alla sicurezza, o addirittura la peggiora.

Non sono d'accordo su praticamente nessuno di questi punti e mi sembra di averlo spiegato. La sicurezza non si improvvisa.
HTTPS?? con le email?? A meno che uno usi una webmail nessuno usa https con le email anche perchè i protocolli per la gestione della posta elettronica sono pop3, imap e smtp. Tali protocolli sono notoriamente insicuri per il fatto che viaggiano in chiaro (a meno di non usare servizi TLS o STARTTLS di cui l'utente comune nemmeno conosce l'esistenza e che comunque sono subordinati al fatto che il provider fornisca tale possibilità).

Lo so che poi per l'autenticazione si deve ad ogni pagina richiesta inviare la password tramite cookie o variabili di sessione, però c'è uno stratagemma che usa numeri casuali e criptazione e decriptazione per far sì che client e server comunichino in modo del tutto sicuro, senza più HTTPS che però è necessaria la prima volta, quando con l'email viene inviata la password che solo server e utente conosceranno e non si comunicherranno mai più, nemmeno con HASH.

Tutto molto confuso... non ci ho capito un granchè...

[microbo87]

Se un minimo conosci i servizi offerti su internet noterai che nessuno adotta questa politica.

Invece, mi è capitato qualche volta, anche se più raramente, chi inviava la password tramite email e se desideravi rinnovarla veniva rigenerata e rinviata sempre per email. Sono le pochissime password alfanumeriche che non ricordo mai (giusto 2-3) e quasi mai uso.

L'email NON è un canale sicuro, sicuramente non più degli altri. A meno che l'utente che scarica la posta non usi connessioni SSL/TLS o STARTTLS

Appunto. Gmail, Hotmail, Yahoo mail, Alice, email concesse dai server che offrono servizi di hosting pagati, ecc. tutti usano HTTPS, ovvero HTTP con protocollo di sicurezza SSL o TLS. Quale email oggi non usa una connessione protetta per scaricare la posta? Ecco, perché dico che l'email è un canale sicuro. Comunque, certo non l'email in sé per sé, facciamo questa precisazione: una email che usa HTTPS è sicura? La risposta me l'hai data, dunque è sì.

Le password non vengono memorizzate sotto forma di hash per impedire che gli amministratori possano accedere alle aree utenti ma piuttosto per impedire che nal caso il server venga violato il pirata di turno non abbia accesso a tutte le password degli iscritti al sito

L'eventuale pirata non avrà accesso alle password in chiaro, ma se è arrivato ad avere un accesso del genere, manco gli servono più le password, perché prende direttamente tutti i dati sensibili memorizzati... Comunque un HASH si può sempre usare, in qualche modo meglio sì che no.

che c'entra lo storage dei dati? Dati critici o credenziali di autenticazione dovrebbe sempre girare su HTTPS.

Lo storage dei dati è un caso in cui i dati che metto sul server servono solo a me. E' l'unico caso in cui posso criptarli con una password nota solo a me e non presente sul server, per cui questi dati potrebbe finire teoricamente ovunque, ma solo io saprò leggerli. Comunque non ha importanza, era solo una parentesi, non è questo il caso che mi interessa.

HTTPS?? con le email?? A meno che uno usi una webmail nessuno usa https con le email anche perchè i protocolli per la gestione della posta elettronica sono pop3, imap e smtp. Tali protocolli sono notoriamente insicuri per il fatto che viaggiano in chiaro

I protocolli pop3, imap e smtp vengono utilizzati quando un'applicazione viene configurata per gestire la posta su server che se ci accedi direttamente usano HTTPS ed il beneficio di HTTPS va a farsi friggere, mannaggia. Effettivamente penso che non pochi utenti abbiamo il cellulare o configurano un account di posta per leggere gli altri account o configurano Thunderbird con questi sistemi... il che non mi consente di utilizzare il canale email per la password. A questo non avevo pensato (perché uso direttamente le email sull'interfaccia del browser e vedo HTTPS sempre). Grazie.

Tutto molto confuso... non ci ho capito un granchè...

La parte finale era poco comprensibile perché non l'ho spiegata, avevo dato solo alcune parole chiave per far intuire un metodo che avevo in mente, però ci tengo a comunicare la password in modo sicuro (insomma se salta questo punto, addio), contavo sull'email, ma non ho considerato che si usa spesso pop3, imap e smtp, mannaggia. Mmmm, la prima alternativa che mi viene in mente è usare il metodo RSA, però senza un garante delle identità c'è il problema dell' "uomo nel mezzo".

Esiste un sistema per impostare alcune email affinché si rifiutino di essere lette o inviate con pop3, imap e smtp? Mi pare proprio di no, ma sarebbe stato risolutivo. Potrei dire agli utenti al momento della registrazione, di leggere l'email inviata direttamente sull'interfaccia concessa dal servizio email che utilizzano senza leggere l'email con pop3, imap o smtp in una seconda applicazione, perché altrimenti c'è la possibilità che in questo frangente qualcuno intercetti la password.

Tutto sommato mi sembra un'operazione meno pericolosa del classico invio della password con HASH. Utenti mediamente esperti seguirebbero l'indicazione di leggere l'email in modo diretto da chi offre il servizio email, molti altri utenti potrebbero restare più confusi, leggere l'email nella classica maniera ed esporsi per un momento ad un rischio intercettazione. Ora come ora, se uno non può avvelersi di HTTPS per il proprio sito, mi sembra il male minore.

[microbo87]

Ho delle email secondarie che raramente leggo su cellulare connettendomi con WiFi al modem di casa, una di queste email la leggo con quella principale di Gmail configurato tramite POP3. Un'altra email ancora che è davvero terziaria (la potrei cancellare praticamente) è sempre configurata con POP3 e letta dalla principale di Gmail.

Che cosa sono andato a controllare? Se c'era la possibilità di attivare SSL. Ebbene sul cellulare SSL è già attivo, i due POP3 su Gmail uno era impostato con SSL (quello secondario come importanza), mentre l'altra non era attivo SSL, ho provato ad attivarlo ma si è rifiutato (servizio non supportato).

Insomma, salvo 1 caso tutti avevano SSL. A questo punto direi che l'email è ragionevolmente sicura, dato il pericolo di POP3 e compagnia i programmi ed i siti cercano automaticamente di impostare SSL, molti se la ritrovano senza saperlo. A questo punto mi sembra chiaro che l'email (per come viene normalmente gestita) sia un canale sicuro di comunicazione.

[microbo87]

Ho saputo di un aspetto che non era mai emerso, relativo all'invio della posta elettronica, che riporto perché questa discussione potrebbe risultare disinformativa, per il punto a cui era giunta.

Se la connessione col server è protetta da SSL, bene, ma non basta, perché quando si invia la posta, questa deve passare dal server di posta del mittente al server di posta del ricevente. Il protocollo usato è MIME che è in chiaro e quindi nonostante la nostra posta l'abbiamo letta e inviata con un canale sicuro, per essere poi effettivamente spedita, viaggia in chiaro. In realtà si potrebbe utilizzare SMIME ed allora tutta la comunicazione dal mittente al destinatario sarebbe sicura... purtroppo quasi nessuno usa SMIME. Peccato, dovrebbero farlo.

C'è anche da dire che una percentuale altissima di email è tutta spam o pubblicità. Quindi fare continuo sniffing in cerca di informazioni sensibili che possano praticamente essere utilizzate a proprio vantaggio, è molto difficile ed è assai remoto che valga la pena questa fatica. Anche perché ad essere "interessanti" sono i conti delle banche che adottano sistemi di sicurezza che non incorrono in questi problemi. Dunque che resta da origliare con tanta fatica? Per esempio indirizzi email da riempire di spam, ma anche qui ci sono ottimi filtri.