C'è un punto interessante nella tua domanda:
I thought about storing his password on his computer, and getting the web page to send it to me. I don't think that would make them feel safer though.
Vuoi che gli utenti siano sicuri o si sentano sicuri? Non è la stessa cosa.
Se memorizzi la password sul tuo server, ne diventi responsabile. Ci sono alcuni trucchi che possono essere utilizzati per ridurre i rischi di perdite, ma i rischi esisteranno ancora. Ad esempio, se si archiviano le e-mail in forma crittografata nel database, il software del server dovrà decrittografarle prima dell'utilizzo, quindi il server deve conoscere la chiave di decrittografia, ma quella chiave non deve essere conosciuta nel database ; può essere memorizzato in un file e decrittografato sul server ( non con capacità crittografiche basate su SQL offerte dal database). Ciò potrebbe fornire una certa protezione contro gli attacchi SQL injection. È una danza delicata: se il server può accedere alle password memorizzate solo , quindi scaricare il intero contenuto del server (ad esempio un'immagine completa del disco rigido) deve garantire anche l'accesso; qualsiasi chiave di crittografia deve essere lì. La crittografia, in questo caso, è una scommessa sull'idea che gli attacchi saranno parziali : un utente malintenzionato scaricherà il contenuto del database, non l'intero disco.
Un sistema migliore potrebbe assomigliare a questo:
- Per ciascun utente u , viene generata una chiave simmetrica casuale K u .
- La password di posta elettronica per l'utente u è crittografata con K u ; questo è ciò che è memorizzato sul server.
-
K u NON è memorizzato sul server, ma sul client.
- Al momento della connessione, K u viene inviato dal client al server. Il server lo utilizza per recuperare la password e-mail, solo nella RAM; la password decodificata e K u non vengono mai scritti su file o database.
Archiviazione di un valore segreto specifico del client sul client, inviato al server: questo è un cookie HTTP. Assicurati di contrassegnarlo Sicuro e Http One e di utilizzare HTTPS per tutte le connessioni.
Con quel sistema:
- La password di posta elettronica non è memorizzata sul sistema client e quindi non verrà messa a rischio quando lo smartphone dell'utente viene rubato.
- La memoria permanente del server (file, database) non consente il recupero della password. Un attaccante che ruba l'intero sistema (afferra le macchine e fa una corsa per farlo) non sarà in grado di ottenere le password, indipendentemente dalla quantità di potenza di calcolo che dedica alle attività (supponendo che la crittografia sia stata eseguita correttamente, ovviamente ) (questo contrasta con l'hashing della password, in cui le password deboli possono ancora essere violate, a un costo).
Tuttavia:
- Se il server viene dirottato "in silenzio", l'utente malintenzionato sarà in grado di osservare le password quando viene utilizzato. Questo è inevitabile nel tuo sistema. L'unico modo per evitarlo sarebbe un sistema di ticketing alla Kerberos , usato dall'email server e sistema client , il server è un semplice relay per il ticket Kerberos; ma il normale server di posta non esegue Kerberos, e nemmeno i sistemi client (in particolare quando il "client" è un po 'di Javascript in una pagina Web).
- Se l'utente perde i suoi cookie (ad es. passa dal suo telefono al suo computer desktop, e non ha un sistema di sincronizzazione tra i due), allora K u è perso e l'utente deve reinserire la sua password di posta elettronica.
Quest'ultimo punto è, ancora una volta, inerente. Se il tuo server non memorizza abbastanza dati per recuperare la password e-mail senza la guida dell'utente, allora ... il server non può recuperare la password e-mail senza l'aiuto dell'utente. Se l'utente è anche indifeso, i dati vengono persi.