Cifratura / decodifica delle informazioni nel database

Question

Cifratura / decodifica delle informazioni nel database

#1 da (3 voti)
#2 da (1 voti)

6

Quindi, supponiamo di avere un messaggio segreto che desidero crittografare e archiviare nel mio database, da cui un utente autenticato può recuperare, decodificare, leggere, aggiornare il messaggio.

EDIT: il problema che sto incontrando è questo: non ha senso usare la stessa password per l'autorizzazione e la decrittografia. Di solito, una password con hash viene memorizzata nel database per verificare l'utente. Ma se uso la password hash per crittografare il messaggio, allora tutto ciò che un hacker deve fare una volta che vede il database decrittografare il messaggio con la password hash

Da alcune ricerche StackOverflow (http://stackoverflow.com/questions/2388256/secure-encrypted-database-design?rq=1), ora correggimi se ho capito male, sembra che la soluzione sia per crittografare il messaggio segreto con chiavi pubbliche, decodificare il messaggio con chiavi private e quindi crittografare simmetricamente queste chiavi private con le passphrase dell'utente. Le chiavi private crittografate possono quindi essere archiviate nel database. Quindi, in sintesi, questo è il modo in cui funziona: l'utente fornisce una passphrase, che decodifica la chiave privata come archiviata nel database, che viene quindi utilizzata per decrittografare il messaggio segreto memorizzato nel database.

Ora, la mia domanda è questa: puoi usare la passphrase sia per l'autenticazione che per decifrare il messaggio? Non voglio che gli hacker siano in grado di indovinare le passphrase fino a quando la chiave privata non viene decifrata correttamente, quindi qualche autenticazione utente (cioè nome utente, password, archivio con password hash nel database) sarebbe buona. Tuttavia, l'idea di dover inserire sia una password per l'autenticazione che una passphrase per decifrare il messaggio sembra eccessiva.

Credo di poter fraintendere il post collegato, ma la mia ultima domanda è come posso strutturare il sistema di sicurezza in modo che il messaggio possa essere crittografato nel database (nel caso in cui qualcuno ottenga l'accesso non autorizzato al database) senza avere la password di una persona è la chiave per la decrittazione.

authentication encryption

posta 08.08.2012 - 18:59

fonte

2 risposte

Leggi altre domande sui tag authentication encryption

Generazione di token unici da chiave API? Qual è il rischio di modificare le autorizzazioni della chiave del registro di EventLog di sicurezza nelle operazioni IT?

score 3 · Answer 1

Sì.

È possibile utilizzare la stessa password per l'autenticazione e per la crittografia dei dati. Ciò che ti serve è derivare dalla password, utilizzando la tua funzione di derivazione della chiave preferita, sufficientemente lungo flusso dipendente dalla password. Quindi si utilizza la prima metà del flusso per l'autenticazione (quella è la parte che si archivia nel database) e la seconda metà come chiave di crittografia.

Per KDF, usa ad esempio PBKDF2 , con SHA-256 come funzione di hash interna. Regola il conteggio delle iterazioni in modo che il calcolo sia abbastanza costoso (un conteggio ad alta iterazione rallenta tutti: il tuo server, e un utente malintenzionato che cercherebbe di indovinare la password; Assicurati di selezionare un nuovo, casuale, abbastanza grande (diciamo 16 byte) di sale per ogni password (si salverà il sale lungo il valore hash nel database). Genera 32 byte con PBKDF2; utilizzare i primi 16 byte come token di autenticazione (memorizzati nel database) e utilizzare gli altri 16 byte per la crittografia (con un sistema di crittografia simmetrica appropriato, preferibilmente uno con controllo di integrità integrato, come EAX .

Se applichi tutto ciò e non compromettere l'implementazione, sarai sicuro che quando sarai hackerato, sarà colpa dell'utente (ad esempio, un utente utilizzerà il nome del suo cane come password).

score 1 · Answer 2

Penso che tu stia puntando a un modello di sicurezza stratificato. Quindi vuoi essere in grado di crittografare i dati usando una chiave, ma quella chiave dovrebbe essere indipendente dalla password. Quindi, se la password viene rubata o violato, i dati non vengono compromessi.

La sicurezza può essere basata su

qualcosa che hai (file SSH fisico, dispositivo secureID, codice SMS che viene inviato una volta verificata la password)
qualcosa che conosci (password)
qualcosa che sei (dati biometrici)

In questo caso, quello che vuoi fare è combinare più cose per fornire una protezione più strong. Hai già una password, quindi è meglio scegliere qualcosa che hai o qualcosa che sei.

La biometria potrebbe essere un eccesso per il tuo scenario, quindi ti consiglierei, qualcosa che hai.

Potresti verificare qualcosa che hanno, come uno di quei pad monouso (dispositivi ID sicuri), o consentire solo la connessione tramite SSH, verificando implicitamente le chiavi SSH (che sono state preregistrate). Puoi anche inviare un SMS a un dispositivo registrato e chiedere all'utente di abbinare il codice. Se è una corrispondenza, decifri i dati. Qui la scelta della chiave non sarebbe così importante. Può essere indipendente dall'utente e anche essere unico per ogni utente.

Per ulteriori consigli di esperti, ti consiglio di passare al link , sperando che qualcuno possa indirizzarti nella giusta direzione.

Questo sta diventando popolare anche come autenticazione a due fattori.