Crittografia a due vie php nel database mysql [duplicato]

0

Mi piacerebbe sapere / sapere come le altre aziende affrontano il problema dell'archiviazione delle chiavi di crittografia. Voglio crittografare l'indirizzo email dell'utente (e altre informazioni sensibili) ma (perché voglio essere in grado di inviare un'email all'utente) ho bisogno di una crittografia bidirezionale per decrittografarlo.

Ho fatto qualche ricerca ma non la capisco ancora del tutto. è per questo che sono per la tua esperienza.

La domanda, che cosa dovresti usare come chiave di crittografia (come la password con hash) o dove / come dovresti memorizzare una chiave generata.

Sarebbe inutile archiviare la chiave nello stesso database perché se venisse compromessa la chiave sarebbe anche trapelata e i dati sarebbero decifrabili. Ma i dati devono essere accessibili dal programma ...

Quindi stavo pensando ( e per favore condividi la tua opinione / competenza ) su un database sqLite che collega la (bcrypt hashed password + mt_rand stringa di caratteri a 64 bit di chiave di crittografia a lunghezza variabile) a un id_utente. Il file sarà accessibile solo dal codice (o dall'esterno se nginx / linux è compromesso). E se un utente richiede dati crittografati, il sistema usa l'id dell'utente per cercare la chiave di crittografia all'interno del database sqlite e usa quella chiave per decodificare i dati dal database mysql.

Un modo migliore sarebbe che anche io non sarei in grado di accedere ai dati (come l'hashing) ma che il sistema sarebbe in grado di decrittografarlo, ma non penso che sia possibile.

nota a piè di pagina, anche se risolverebbe questo problema lasciando la risposta, per favore condividi anche le risorse , non solo aiuterebbe a risolvere il mio problema. Ma anche per imparare a migliorare la sicurezza.

    
posta goosmaster 20.09.2017 - 17:00
fonte

1 risposta

2

Ciò che fai qui dipende dal tuo modello di minaccia e da quale scenario di attacco stai cercando di difendere. Presumo che tu stia cercando di proteggere da una situazione in cui un utente malintenzionato può leggere il contenuto del database (ad esempio tramite una vulnerabilità di SQL injection) ma non il contenuto del file system. Inoltre, assumerò che ti interessi per la riservatezza e non l'integrità o l'autenticità.

Vale la pena notare che sarà necessario bloccare le autorizzazioni dell'utente del database per impedire a un'iniezione SQL di ottenere l'accesso al filesystem tramite comandi come LOAD DATA INFILE , altrimenti l'accesso al database implicherà intrinsecamente anche l'accesso al filesystem nella maggior parte dei casi.

Il modo generale per proteggere i contenuti del database rispetto a uno scenario di questo tipo consiste nel disporre una chiave simmetrica memorizzata esternamente al database, ad es. in una variabile di configurazione o memorizzata nel proprio file. Quindi, per ogni elemento di dati che si desidera crittografare, si genera un IV e crittografare i dati con AES in modalità CBC, quindi archiviare i dati IV e crittografati come colonne nel database. È quindi possibile decrittografare il valore trovando la riga che si desidera decrittografare, leggere la IV e l'indirizzo e-mail crittografato, quindi eseguire una decrittografia AES-CBC utilizzando la chiave caricata dal file chiave.

Ciò significa, tuttavia, che non è possibile effettuare ricerche nella tabella utenti tramite l'indirizzo email. Scott Arciszewski ha scritto di recente un ottimo post sul blog costruzione di database crittografati ricercabili che può aiutarti se questo è un requisito.

    
risposta data 20.09.2017 - 17:16
fonte

Leggi altre domande sui tag