Ti salverò il dettaglio dei problemi, ma fammi sapere se hai bisogno di ulteriori informazioni che non sto menzionando qui.
L'impostazione di base è che ho un'applicazione web e nel browser l'utente inserirà alcune informazioni relativamente sensibili che verranno trasmesse al server tramite https. A differenza delle password per gli accessi, queste informazioni inviate dagli utenti dovranno essere disponibili / leggibili per gli utenti in futuro e quindi crittografate in modo reversibile.
Ho trovato alcuni post pertinenti, ma non sono sicuro che li capisco completamente. Il mio pensiero iniziale era il seguente:
- Chiedi all'utente di inviare un passcode insieme alle informazioni sensibili.
- Sul lato server, crittografo le informazioni sensibili utilizzando il loro passcode tramite AES ecc.
- Conservo le informazioni crittografate nel mio database e scarto il passcode.
- Quando l'utente deve vedere le informazioni sensibili, gli chiedo di digitare nuovamente il codice di accesso, che viene poi inviato al server.
- Una volta ottenuto il codice di accesso, lo uso per decrittografare le informazioni dal mio database e inviare le informazioni decodificate al browser.
In conclusione, non memorizzo mai il passcode utilizzato come chiave per la crittografia . Ora questo sembrerà ingenuo e ampio, ma qualcuno può darmi un'idea di se / quanto sarebbe sicura questa procedura? La mia ipotesi è che, poiché la chiave non si trova da nessuna parte sul server, le informazioni sono sicure / insicure come il metodo di crittografia AES stesso.
Come crittografare i dati sensibili nel database di un'app Web?
Ho letto la risposta dal link precedente, che implica diversi livelli aggiuntivi di crittografia. Posso probabilmente implementarlo, ma sono quei passaggi aggiuntivi necessari per il mio scopo? E se sì, come hanno fatto quei passaggi a renderlo più sicuro di quello che ho descritto sopra? Ad esempio, nel caso peggiore, se l'intero server è compromesso, quest'ultimo metodo sarebbe più desiderabile?
Grazie!