Utilizzo di AES per crittografare i dati dell'utente

3

Non conosco quasi nulla della crittografia, e fondamentalmente sto solo cercando qualcuno che controlli ciò che sto facendo e mi dica se sto facendo un casino.

Ho l'utente che inserisce alcune informazioni sensibili e una password. Quindi utilizzo quella password come chiave per AES per crittografare le informazioni e memorizzare il testo cifrato. Successivamente, se l'utente desidera recuperare le informazioni, reinseriscono la password e io uso AES per decrittografare il testo cifrato.

Questo è sicuro? In questo momento sto solo usando la password direttamente come chiave di crittografia. Ho visto PBKDF2 menzionato molto in contesti simili, ma non sono sicuro di quale sia il punto. Non sto mai memorizzando la password da nessuna parte. Se l'utente dimentica la sua password, le informazioni andranno perse per sempre.

Se possibile, mi piacerebbe poter archiviare il testo cifrato nei cookie di un browser web (anche se questo non è assolutamente necessario), quindi è importante che le informazioni siano sicure.

Note di implementazione:

Sto usando CryptoJS, che credo generi a caso il sale e IV. Non conosco davvero i dettagli, sembra solo fare tutto per me.

Parte delle informazioni che sto memorizzando è il nome dell'utente, quindi non so se questo mi apre a un attacco in chiaro o qualcosa del genere.

    
posta sjelin 13.11.2013 - 05:55
fonte

2 risposte

4

La risposta è nel nome: PBKDF è l'acronimo che sta per "Funzione di derivazione chiave basata su password". Il suo intero compito è prendere una password come input e generare una chiave di crittografia come output.

Il motivo principale per cui abbiamo bisogno di funzioni come questa è che algoritmi di crittografia come AES prendono una chiave di dimensione fissa. Per definizione, AES-128 richiede una chiave a 128 bit (16 byte). Ma la password di un utente è semplicemente una serie di byte - forse è 50 byte, forse è solo 5 byte, a seconda di ciò che l'utente ha inserito. Pertanto, se si desidera utilizzare la password per crittografare, in qualche modo è necessario incorporare tale password negli esatti 16 byte richiesti da AES. Ovviamente stai già facendo qualcosa del genere per alimentare la tua password corrente in AES, anche se non la riconosci con quel nome.

Un PBKDF è progettato per prendere comunque molti byte che l'utente inserisce, mescolare tutti insieme usando un algoritmo (chiamato hash) e quindi produrre una stringa di bit adatta per l'uso come chiave. Se hai bisogno di 16 byte per la tua chiave AES, prendi semplicemente i primi 16 byte che escono dalla funzione PBKDF.

Pensa se non hai usato un PBKDF, ma hai invece richiesto agli utenti di inserire almeno una password di 16 byte. Senza un PBKDF, cosa succede a tutto dopo il 16 ° byte? Diventa privo di significato. Se digito una password di security.stackexchange.com , potrei anche digitare una password di security.stackexPOSITION@ORG o solo security.stackex e ognuna di esse funzionerebbe ancora. Ma poiché un PBKDF mescola tutte quelle lettere insieme, tutte contribuiscono alla chiave e l'intera password viene controllata.

La prossima ragione per cui abbiamo bisogno delle funzioni PBKDF è che le password hanno un sacco di prevedibilità in esse, perché gli umani di lingua inglese di solito usano solo caratteri negli intervalli di a-z, A-Z e 0-9. Nonostante il fatto che ci siano 8 bit in un byte, una password di 10 caratteri non fornirà 80 bit di incertezza nella chiave; la maggior parte fornirà 47 bit (o meno) di incertezza, e questo significa che può essere facilmente indovinato da un moderno aggressore. Ma poiché un PBKDF prende in considerazione tutte le lettere della password, rende una password di 20 caratteri molto più strong di una password di 10 caratteri e migliora la sicurezza degli utenti.

Una routine più strong come PBKDF2 fa un passo più lontano di un semplice PBKDF nell'aiutare a proteggere da un attacco indovinatore di password, rendendo l'operazione necessaria a una grande quantità di risorse di elaborazione. Un utente malintenzionato che desideri provare a indovinare ogni parola del dizionario avrà bisogno solo di pochi millisecondi per provare ogni parola come chiave di decodifica. Un utente malintenzionato che deve eseguire 10.000 hash con PBKDF2 impiegherà ore o giorni a provare l'intero dizionario.

    
risposta data 13.11.2013 - 20:03
fonte
0

Per quanto ne so, questo dovrebbe andar bene .. Ho fatto cose simili in PHP per compiti simili. Inoltre, la memoria dell'utente è uno dei posti migliori in cui memorizzare la chiave AES. O almeno in parte. Sai, perché se lo memorizzassi nel database o in un file sul server, una volta che il database o il server è sotto attacco, i dati non sono più sicuri.

Mi assicurerei che la password dell'utente sia abbastanza strong e abbastanza casuale. Implementerei alcuni soliti controlli per lettere maiuscole, numeri e anche punti o qualcosa del genere. L'utente dovrebbe sapere che questa è la password utilizzata per memorizzare i suoi dati e dovrebbe essere diversa dalla password che usa per accedere (se hai qualcosa del genere). E anche il sale (o la seconda parte della chiave) deve essere conservato in modo sicuro, ad es. anche AES nel database con la chiave memorizzata sul server. Qualcosa del genere.

Per semplificare il pbkdf, se ho capito bene: è un modo per "convertire" la password dell'utente nella chiave di crittografia effettiva. Quindi se lo usi in connessione con AES, sarebbe il migliore.

Un'altra cosa sono sicuro è che alcuni degli esperti qui segnalerebbero più inconvenienti di questo approccio. Tuttavia, penso che AES sia abbastanza sicuro per i prossimi decenni. I ragazzi di 1Password sembrano pensarlo anche .

    
risposta data 13.11.2013 - 07:21
fonte

Leggi altre domande sui tag