Gestione dei dati sensibili per un'applicazione Web

0

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:

  1. Chiedi all'utente di inviare un passcode insieme alle informazioni sensibili.
  2. Sul lato server, crittografo le informazioni sensibili utilizzando il loro passcode tramite AES ecc.
  3. Conservo le informazioni crittografate nel mio database e scarto il passcode.
  4. Quando l'utente deve vedere le informazioni sensibili, gli chiedo di digitare nuovamente il codice di accesso, che viene poi inviato al server.
  5. 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!

    
posta Michael Xu 24.01.2018 - 10:04
fonte

2 risposte

-1

Penso che uno dei problemi principali del primo approccio sia che una volta perso il passcode da parte dell'utente, non c'è assolutamente modo di recuperarlo (senza brute-force). A seconda del tipo di informazioni che potrebbe essere un requisito però.

Quindi, arrivando all'articolo collegato spiegherà come risolve quel problema. Offre più comfort e consente di implementarlo nell'algoritmo di modifica della password sperabilmente esistente per generare sempre un nuovo KEK e crittografare nuovamente il DEK. È improbabile che la password venga dimenticata

    
risposta data 24.01.2018 - 10:16
fonte
-2

Hai due problemi:

1) Se si utilizza una chiave generata da password per crittografare i dati dell'utente, sarà necessario decodificare e crittografare nuovamente tutti i dati se l'utente reimposta la propria password.

Soluzione : utilizza l'approccio proposto nel link che hai pubblicato (DEK e KEK).

2) È normale che gli utenti dimentichino le loro password, soprattutto se non effettuano il login così spesso e la decrittografia dei dati dipende sempre dalla password.

Soluzione proposta : usa qualcosa che gli utenti difficilmente dimenticano, cioè i loro indirizzi email.

Crittografia:

  1. Chiedi agli utenti di inserire il loro indirizzo email
  2. Concatenare l'indirizzo e-mail con un salato e cancellarli per generare una chiave che verrà utilizzata per crittografare la password
  3. Tutto questo dovrebbe essere fatto dal lato utente (non dal lato server)
  4. Mantieni il sale e la password crittografata nel tuo database (non dovresti tenere le loro e-mail, o puoi?)

Se l'utente dimentica la sua password:

  1. Chiedi all'utente di inserire il loro indirizzo email
  2. Verifica la proprietà dell'indirizzo email inviando un'email di verifica
  3. Utilizza l'indirizzo email insieme al sale che devi ricreare la chiave utilizzata per decrittografare la password.

Non vuoi generare KEK dall'indirizzo email perché dovrai sempre verificare la proprietà dell'email ogni volta che l'utente accede alla tua app Web.

    
risposta data 22.10.2018 - 09:15
fonte

Leggi altre domande sui tag