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è...