Quanto è sicuro questo piano di crittografia?

0

Sto cercando di trovare un buon modo per archiviare i dati crittografati di un utente in modo tale che solo l'utente possa accedervi.

Ho una chiave master situata all'esterno della web root, chiamata $serverKey . E quando un registro utente è in, ho messo un altro lato client chiave con sessionStorage.setItem() . il $clientKey è impostato da sha256 della loro password in testo semplice (che ovviamente non è memorizzata da nessuna parte). Quando l'utente invia i dati, utilizzo openssl_encrypt() con $serverKey.$clientKey e lo memorizzo nel mio database.

Quindi il mio obiettivo è che per hackerare i dati dell'utente devi in qualche modo ottenere la chiave master e la chiave del cliente. Quali sono i buchi in questo piano? Mi rendo conto che cambiare e dimenticare le password causa problemi, ma ora lo ignoro.

    
posta twharmon 25.08.2016 - 23:33
fonte

2 risposte

1

in such a way that only the user can access it.

Non ha senso crittografare i dati che il server deve operare (a meno che non si stia sfruttando la malleabilità). I crittosistemi completamente omomorfi sono ora non fattibili e non sono studiati così bene, quindi è impossibile proteggere i dati dell'utente da una parte privilegiata.

Quindi supponiamo che tu provi a mitigare l'attacco offline, quando un avversario ottiene un dump di server db con i dati dell'utente al suo interno e prova a decodificarlo senza conoscere le password dell'utente. L'avversario non è in grado di modificare il codice in esecuzione sul server e non è in grado di monitorare i dati che il server riceve / trasferisce da / a un altro utente.

Usi SHA-256 dei dati con scarsa entropia, il che significa che è facile creare una forza bruta del dizionario. Quindi il mio primo consiglio è di sostituire SHA-256 con alcune KDF (funzioni di hash intenzionalmente rese resistenti alla forza bruta a costo di tempo di esecuzione e memoria), ad esempio il Arresta KDF e dispone di sale personale per ogni utente.

Cambiare le password non è un problema, perché sei in grado di ricodificare i dati.

    
risposta data 26.08.2016 - 00:35
fonte
0

Dividiamolo in due:

Crittografia dei dati dell'utente con la loro password

Certo, perché no, se i dati sono privati. In pratica, il server dovrà gestirlo in testo in chiaro, ma i dati possono essere lasciati crittografati fino a quando l'utente non ha effettuato l'accesso. Sebbene in un forum di messaggi, i messaggi che dovrebbero essere letti da altri utenti non possono essere soggetti a questo trattamento, quindi funziona solo per i messaggi privati (indirizzati a un singolo utente oa un gruppo noto di utenti).

Come sempre, non si desidera utilizzare alcuna password direttamente come chiave, ma eseguirla attraverso alcune funzioni di derivazione della chiave come PBKDF2 . Ciò rallenterà la ricerca della password tramite la forza bruta e darà la possibilità di generare chiavi più lunghe rispetto alla password (nel caso sia necessario).

Per quanto riguarda le modifiche alle password, la prassi abituale consiste nel generare una chiave strong casuale, utilizzata per crittografare i dati e quindi archiviare questa chiave crittografata con (una chiave basata su) la password dell'utente. In questo modo, la modifica della password richiede solo la crittografia della chiave master, non tutti i dati.

Anche se il lato negativo è sempre che se il server è compromesso, può essere configurato per salvare la password dell'utente in testo normale al prossimo accesso, o semplicemente salvare tutti i dati non crittografati.

Cifratura di tutti i dati con la chiave del server

Ecco, mi chiedo quale sia la minaccia prevista? Un attacco software che perde tutti i dati (crittografati) o l'hardware del server viene perso? La protezione da hardware smarrito richiederebbe la crittografia dei dati con una chiave che è non sul sistema stesso , ma forse è stata inserita manualmente. Il modo più semplice per farlo sarebbe utilizzare una soluzione di crittografia a disco intero.

Per quanto riguarda un attacco che in qualche modo perde tutti i dati, ma non consente la modifica del codice stesso, sicuramente, la crittografia con una chiave fissa del server dovrebbe aiutare. Ma è necessario, se i dati sono già crittografati con la chiave dell'utente? Com'è possibile che i dati crittografati perdano ma non la chiave del server, dato che il server avrà bisogno di quella chiave per quasi tutte le operazioni che coinvolgono i dati? Devo dire che non lo so.

(Se stai pensando alle iniezioni SQL, meglio correggere le tue pratiche su quello in cui si trova il problema. D'altra parte, se stai pensando a una vulnerabilità che porta all'esecuzione di codice arbitrario, l'autore dell'attacco ha appena ricevuto la chiave del server anche.)

Combinazione dei due

Il modo ovvio per combinare due chiavi sarebbe quello di crittografare i dati due volte, usando entrambi i tasti, in modo tale che i dati memorizzati siano C = E (K2, (E (K1, P)). Questo è ciò che accadrebbe nel fine se si memorizzano i dati crittografati su un'unità crittografata, ma è un po 'uno spreco o lavoro.

Un altro modo sarebbe quello di ricavare la chiave di crittografia effettiva dalle due chiavi (server e utenti) usando un KDF (di nuovo). Anche se con input dall'aspetto casuale, penso che potresti farla franca combinando due chiavi a lunghezza fissa con un hash strong come SHA-256, quindi C = E (H (K1, K2), P).

    
risposta data 26.08.2016 - 14:29
fonte

Leggi altre domande sui tag