Decrittografia dei segreti multiutente nell'applicazione web multi-tenant

Invece di usare il tuo sistema di sessione per tenere traccia della chiave, potresti provare un'alternativa.

Assegna al tuo utente un cookie sicuro limitato nel tempo, limitato nel dominio e limitato nel percorso con un "segreto di decrittazione" appena casuale che generi quando controlli le credenziali dell'utente nel gruppo aziendale.

Se la password è valida, prima del completamento della procedura di accesso, decrittografare la chiave privata con la password e ricodificarla con il "segreto di decrittografia". Memorizzare la chiave privata reencrypted nella sessione. Il tuo utente è ora indirizzato alla tua pagina webmail normalmente e le variabili utilizzate nella fase di login sono perse.

Ora, ogni volta che l'utente naviga nel tuo sito webmail, invierà costantemente il "segreto della decrittografia" come cookie. Questo può essere usato dallo script sul lato server, insieme alla chiave privata reencrypted, per decrittografare qualsiasi e-mail, se necessario.

Tuttavia, come @Vitaly menzionato, non si ottiene la perfetta ignoranza sul lato server. Un amministratore di sistema rogue potrebbe, se davvero lo desidera, catturare i cookie installando e indirizzando un utente a una pagina specifica. Potrebbe anche catturare i pacchetti HTTP, soprattutto se non sono già crittografati con TLS (il che renderebbe la maggior parte inutile). Lui / lei potrebbe anche ispezionare la memoria del server. Puoi anche ottenere la password con uno qualsiasi di questi metodi, dato che sei all'interno del server.

Tuttavia, questo schema garantisce che il segreto di decrittografia non verrà memorizzato sul server e non richiede alcuna decrittazione sul lato client, nello stesso modo in cui le password non sono in genere memorizzate nel database. Richiederebbe all'amministratore di sistema uno sforzo effettivo per leggere le e-mail, ad esempio, non si potrebbe semplicemente inciampare sulla chiave privata. E questo potrebbe essere abbastanza buono per il tuo modello di minaccia.

The only problem is: by reading the session files, sysadmins are still able to decrypt messages of logged in users. Is there any protocol to solve this?

Stai chiedendo l'impossibile - per un sistema che fornirebbe agli utenti servizi di decrittografia e crittografia senza mantenere alcuna conoscenza su come lo fa, in qualsiasi momento (altrimenti gli amministratori di sistema saranno in grado di decrittografare anche i messaggi!).

Devi decidere chi ti fidi e in quale misura, perché devi fidarti di qualcuno - alla fine è l'hardware che esegue il tuo codice, non tu stesso.

Il maggior rischio di archiviare il lato client chiave è un attacco XSS.

La sicurezza della tua applicazione dipende in gran parte da ciò che stai evitando con successo. Questo potrebbe rivelarsi particolarmente difficile in quanto un attaccante ha presumibilmente un ampio margine di manovra nella creazione di un messaggio in quanto le e-mail hanno un'ampia varietà di caratteri e codifiche consentite.

Faccio un bel pò di sviluppo .net e il numero di volte in cui vedo una domanda sullo stackoverflow come "Come posso visualizzare il contenuto HTML fornito dall'utente sul mio sito web" con una risposta come "Usa @Html.Raw() " è incredibile. La maggior parte dei framework web ha meccanismi di escape eccellenti per prevenire gli attacchi XSS, ma molti sviluppatori non ne sono consapevoli o quando li ignorano attivamente.

Non sto dicendo che non è possibile visualizzare correttamente un'e-mail in formato html su una pagina web senza analizzare possibili attacchi, solo che sarebbe molto facile fare un errore.

Nel complesso, ritengo che archiviare la chiave a livello locale mi renderebbe piuttosto nervoso, dato il probabile contenuto del messaggio e il fatto che ogni utente malintenzionato deve solo mandare email a un utente per inserire potenzialmente il codice.

Detto questo, la chiave di decrittografia è utile solo se hai accesso ai contenuti crittografati e un attacco XSS mirato contro il tuo sito web potrebbe probabilmente leggere comunque tutti i messaggi di un utente.