guida per la scelta di un metodo di crittografia per una colonna del database

Question

guida per la scelta di un metodo di crittografia per una colonna del database

#1 da (6 voti)
#2 da (2 voti)

2

Sto memorizzando alcuni numeri di telefono nel database che dovrebbero essere tenuti completamente segreti (dovrebbero essere accessibili via web). A proposito, a causa della posizione di queste persone, ho bisogno di evitare ogni possibilità di perdita dei loro numeri. Quindi, l'unica soluzione a cui potrei pensare è la crittografia.

Dato che il database potrebbe contenere molti dati, non cripterò interamente il database. Inoltre, in realtà preferisco usare una chiave diversa per ogni persona per crittografare i loro numeri di telefono, quindi in caso di perdite di una chiave, gli altri numeri di telefono dovrebbero essere al sicuro almeno. Il problema è che altre persone hanno anche bisogno di inviare messaggi SMS tramite l'applicazione attraverso un'interfaccia web e anche alcune persone più privilegiate hanno bisogno di vedere questi numeri, quindi devo anche rendere questi numeri visibili alle altre persone privilegiate.

Mi chiedo qualcosa di simile a una struttura a chiave pubblica / chiave privata, ma è troppo per crittografare un numero di telefono a persona, e inoltre ci sarebbe un problema per i nuovi utenti, perché i numeri precedenti non lo facevano t crittografato con le loro chiavi pubbliche.

Quindi, c'è qualche soluzione che potresti raccomandarmi? forse dovrei rivedere o aggiornare la struttura di come sto cercando di farlo, eh?

database security encryption

posta Mahdi 22.10.2012 - 15:43

fonte

2 risposte

2

Quindi, hai un database che supporta un'applicazione web. L'applicazione web (e altre applicazioni secondarie) devono avere accesso a un numero di telefono.

Suppongo che tu abbia sufficiente sicurezza nel lato dell'applicazione web per impedire alle persone di ottenere dati che non dovrebbero avere.

La tua preoccupazione è che se qualcuno con un accesso sufficiente (accesso corretto o mal ricevuto) guarda al database, non vuoi che quella persona possa vedere i numeri di telefono in chiaro.

Pubblico / privato è probabilmente eccessivo e inutile. Anche chi ha accesso al programma Web eseguendo l'inserimento e il recupero del numero di telefono sarà in grado di eseguire il recupero e la decodifica.

Vorrei invece fare qualcosa sulla falsariga della crittografia simmetrica dove c'è solo una chiave. L'app Web lo utilizza per crittografare prima di inserire il database e decrittografarlo quando è necessario per la visualizzazione. Anche altre app utilizzerebbero la stessa chiave.

Se la chiave è compromessa, decifri tutti i dati e ri-crittografalo con una nuova chiave.

Vi incoraggio vivamente a considerare l'aggiunta di ulteriori "junk" ai dati in modo che non vengano decodificati in modo triviale (se sono stati codificati 10 caratteri e si sa che sono tutti caratteri che corrispondono a [2-9][0-9]{9} , il la crittanalisi dei dati potrebbe essere eseguita piuttosto rapidamente nel caso in cui i dati siano compromessi.

risposta data 22.10.2012 - 15:58

fonte

Leggi altre domande sui tag database security encryption

Spiegazione necessaria, per l'approccio "Chiedi, non dire"? [duplicare] Informazioni sugli oggetti anonimi

score 6 · Accepted Answer

Per la massima sicurezza contro i compromessi, non conservare i numeri di telefono a meno che non sia necessario. Sembra che tu non abbia una scelta in merito.
Obfuscare i numeri di telefono prima di crittografarli.
- Una semplice offuscazione potrebbe essere quella di riorganizzare i numeri in base a un modello predefinito.
- Una confusione più avanzata sarebbe quella di salare il numero e quindi offuscare. Dovresti memorizzare questo sale insieme al numero.
- Un approccio ancora più avanzato sarebbe quello di generare il numero di sale in base ad altre caratteristiche dei dati dell'utente.
Crea le routine di offuscamento e salatura nel codice al di fuori del database. Una procedura memorizzata potrebbe essere più veloce, ma la procedura memorizzata è potenzialmente inclusa nel database compromesso. Le routine esterne ignorano tale problema in una certa misura e richiedono un ulteriore grado di reverse engineering per trovare la loro funzionalità.
- Un ulteriore vantaggio qui è la possibilità di inserire un meccanismo di autenticazione aggiuntivo in modo da impedire ai DBA di accedere ai numeri di telefono poiché l'unico modo per accedere al numero di testo libero è tramite l'applicazione fornita.
Considera l'utilizzo delle funzionalità di crittografia native del database in quanto dovrebbe semplificare la creazione della gerarchia di accesso menzionata.

Non posso dire di raccomandare tutte le combinazioni di coppie di chiavi pubbliche / private che stai suggerendo. Il sovraccarico nel mantenere questo sarà troppo. Inoltre complicherà la gerarchia di accesso che desideri.