Come dovrebbe funzionare l'autorizzazione della webmail?

Per garantire che solo l'utente abbia la chiave per il suo account IMAP, puoi salvare le credenziali di accesso nella tua sessione simmetricamente crittografate da una chiave, che è memorizzata in un cookie . Quindi l'utente può sbloccare le credenziali di accesso con il suo cookie, senza che il server web non possa accedere.

Ovviamente devi assicurarti che tutte le occorrenze delle credenziali vengano sovrascritte se non utilizzate più e non sono leggibili da altri processi.

Se si dispone di un utente malintenzionato sul server Web, sarà in grado di leggere i dettagli della sessione, le credenziali crittografate. Se è anche in grado di ottenere il cookie intercettando la connessione, si ha comunque un problema.

Poiché l'autore menziona il suo prodotto è come Roundcube o Squirelmail. So come funziona Roundcube.

Bene, la webmail di Roundcube NON ha il proprio metodo per accedere agli utenti. Quello che voglio dire è che non esiste un database che memorizzi nulla sull'utente. Roundcubes prende le credenziali dell'utente fornito e le mette direttamente in imap_open() .

1. Se stabilisce una connessione con mailserver, Roundcube registra l'utente.
2. Se non stabilisce una connessione con mailserver, Roundcube dice "credenziali non corrette".

Quindi la password in questa parte: user- > webserver. È lo stesso di questa parte: webserver- > mailserver.

Questo rende più semplice l'applicazione. Tuttavia, per quanto ne so, la password in chiaro o la password crittografata devono essere memorizzate tra quelle richieste, ma non sono sicuro di come è stato fatto in Roundcube.

Immagino che potresti semplicemente memorizzarli nel cookie di sessione (cookie ecnrypted come menzionato nella tua domanda). Pertanto la password non viene salvata sul server in alcun modo, vola solo tra server e utente su ogni richiesta web. Poiché è crittografato, non può essere trapelato fino a quando la chiave di crittografia segreta sul server non è trapelata.

ci sto pensando un po 'perché non dovresti mai memorizzare le password degli utenti in testo semplice. quindi ho trovato una soluzione possibile per te.

Quando un utente si iscrive a un nuovo "servizio" sul proprio account (ad esempio aggiunge gmail o yahoo, ecc.), ciò che si dovrà fare è:

1. Chiedi nuovamente all'utente la password del sito (e confermala)

2. Hash la loro password di nuovo con un nuovo salt casuale (che dovresti memorizzare) (con un algoritmo hash diverso da quello che usi per il tuo archivio di password principale) NON CONSERVARE QUESTO !! da ora in poi mi riferirò a questo come KEY_A

3. genera una chiave dsa o rsa con password con KEY_A come password per il file di chiavi. Questo sarà usato come chiave di enctyption per il prossimo passo

4. Utilizza un metodo di crittografia sicura (forse mcrypt se in php dal momento che è incorporato) e memorizza la loro password 'criptata'

5. Quando un utente effettua l'accesso e una nuova sessione viene creata rehash la propria password con lo stesso metodo utilizzato nel passaggio 2, crittografarla con una chiave derivata da qualcosa che è univoco per la propria sessione ma non memorizzata (Diciamo user_agent + session_start_time + il loro indirizzo IP + un sale specifico dell'utente). Archivia questo valore crittografato in un cookie http_only, cancella detto cookie al logout, costringili a effettuare nuovamente il login se il cookie non è presente.

Ora hai un metodo per archiviare i loro gmail / hotmail / etc. le credenziali in un modo in cui non hai modo diretto di sapere come decrittografarle senza la password che usano per il tuo servizio.

Molto probabilmente sarà anche prudente assicurarsi di non archiviare alcuni dei componenti utilizzati nella crittografia del cookie (quindi disabilitare almeno la registrazione dell'agente utente nella configurazione del server web.)

Ora per poter eseguire un accesso a iMap (o qualcosa di simile, dovresti semplicemente decifrare il cookie http_only dal punto 5 per ottenere KEY_A, usare KEY_A per sbloccare la chiave RSA / DSA, quindi usare la chiave sbloccata per decifrare la password al loro servizio, quindi eseguire la transazione iMap, e solo per essere paranoico ri-zero (in php puoi semplicemente chiamare unset ()) le variabili che contengono la loro password in chiaro, KEY_A, e la loro chiave rsa / dsa sbloccata il linea di codice dopo che non sono più necessari.

Inoltre, assicurati che anche il tuo servizio DNS sia configurato in modo sicuro. (forzare DNS-SEC, forse anche impostare la risoluzione DNS dei server Web per passare attraverso un'interfaccia di rete di servizio e non quella visibile sul Web ed eseguire la risoluzione DNS tramite un indirizzo IP visibile non correlato.) Assicurarsi che il proprio https i certificati sono completamente al top.

Poiché invierai in modo efficace le password private delle persone sul Web, l'ultima cosa che desideri è l'inondazione dell'indirizzo IP del tuo server web con il reindirizzamento dei pacchetti di risoluzione DNS di udp consente di dire "mail.google.com" a un proxy imap personalizzato che hanno creato allo scopo di sniffare le password.

L'unico svantaggio di questo metodo (che mi viene in mente) è quando l'utente cambia la password per il servizio che dovrà reinserire la password a tutti gli altri provider di posta elettronica che hanno registrato con esso. (perché la password crittografata memorizzata non sarà più valida.)

E ultimo ma non meno importante (im supponendo che questo sarà fatto, ma non ho modo di esserne sicuro.) cancella TUTTI il codice di debug relativo a queste routine prima di andare in diretta!

L'intera chiave per questo è garantire che KEY_A non possa essere derivato da qualsiasi cosa tu stia memorizzando (quindi non scorciare semplicemente rifilando l'hash della loro password, hash in un modo diverso, con un diverso salt.)

Perché non si memorizzano le credenziali del server di posta come parte dei dati della sessione del server web. Una volta che l'utente digita il nome utente e la password del server di posta nella tua applicazione client webmail. Mantieni queste informazioni nel server web / sessione utente.

Tuttavia, questo significa che ogni volta che l'utente accede alla webmail dovrà autenticare la propria identità almeno due volte per il server Web che ospita il client webmail e uno per il server di posta che ospita le email degli utenti. In tal caso, potresti avere un problema di usabilità. Alcuni utenti si lamenteranno della parte in cui devono fornire le credenziali per il server di posta ogni volta che effettuano l'accesso. Perché non si memorizzano le credenziali del server di posta nello stesso database in cui si memorizzano le credenziali del client Webmail?