2013-07-01 23 views
5

Sto considerando l'utilizzo della gemma attr_encrypted per la crittografia a livello di campo in un'app Rails. Come posso generare una chiave di crittografia per l'uso con questo gioiello?Come generare la chiave di crittografia da utilizzare con attr_encrypted

Aggiornamento:

La documentazione per Encryptor, che è la crittografia di base usato da attr_encrypted, afferma quanto segue (in Utilizzo | Base):

secret_key = Digest::SHA256.hexdigest('a secret key') 
encrypted_value = Encryptor.encrypt('some string to encrypt', :key => secret_key) 

Direi che a secret key può essere alcuna arbitraria -length random string e la chiamata a hexdigest calcolerà una stringa appropriata di lunghezza fissa da esso. È questo il modo consigliato per farlo?

+0

Ho provato a rispondere, ma ho una domanda: chi (o che tipo di scenario) stai cercando di mantenere segreti i dati in chiaro? –

+0

Alcuni campi del database devono essere crittografati a riposo principalmente per scopi di backup off-site (in cui il sistema di backup off-site non ha accesso alla chiave di crittografia). –

+0

In tal caso, suppongo che il sistema off-site abbia accesso ai dati, ma non la configurazione o il codice sorgente? Probabilmente dovrei comunque errare nei confronti della configurazione per memorizzare almeno parte della chiave, e usare l'abilità della gem per chiamare un metodo per recuperare la chiave corretta come modo di alimentarla. Ma se il codice sorgente è protetto indipendentemente dai dati di backup anche l'hard-coding delle chiavi di cifratura per campo è praticabile. –

risposta

6

La chiave è solo una stringa, qualsiasi stringa lo farà, si vuole solo tenerlo lontano da persone a cui non è permesso vedere i dati in chiaro. Potresti semplicemente generare una chiave usando SecureRandom.base64. Ciò lo renderebbe praticamente impossibile da usare con la forza bruta, con uno sforzo minimo da parte tua.

La cosa interessante qui è la gestione delle chiavi. Le opzioni disponibili con questa gemma sembrano essere:

  • Inserire la chiave nell'applicazione. Ciò impedisce la lettura "accidentale" di dati sensibili, ad es. un DBA o un tecnico di supporto, ma non è sicuro da chiunque sappia come funziona la gemma, se possono accedere sia al codice sorgente che al database.

  • Riferimento a un metodo denominato che determinerà la chiave. Questo è più interessante, ma attenzione: mettere la chiave nel database non aggiunge molta sicurezza. Qualcuno che può accedere al database e al codice può fare lo stesso come se il valore fosse hard-coded.

È possibile migliorare le cose un po ', o almeno avere il team di sviluppo separato dai dati crittografati, avendo l'un'applicazione di leggere almeno una parte della chiave da una posizione che gli sviluppatori (o forse solo la maggior parte degli sviluppatori) non può accedere in produzione. Andare oltre è più difficile, almeno con questa gemma così com'è, perché l'applicazione dovrà essere eseguita con l'accesso alle chiavi di crittografia/decrittografia.

Se questo è abbastanza buono dipende dal motivo per cui si stanno crittografando i dati in primo luogo.

+0

+1. Grazie, Neil. Lo scopo principale della crittografia nel mio caso è la crittografia a riposo dei dati nei backup del database che saranno fuori sede e fisicamente separati dalla chiave.La chiave verrà inoltre mantenuta separata dal codice: molto probabilmente, verrà impostata tramite una variabile di ambiente che verrà impostata solo sul valore della chiave di produzione sul server di produzione. La chiave non sarà incorporata nel codice sorgente dell'applicazione. –

+0

Quanto deve durare la chiave generata? –

+0

L'output predefinito da 'SecureRandom.base64' dovrebbe essere adeguato (~ 22 caratteri diversi), a parte il fatto che probabilmente selezionerei dire 20 caratteri in più, dato che puoi permetterti di avere qualcosa che sarebbe scomodo da digitare. Rendendolo extra lungo non aumenta davvero la sicurezza per te IMO. –

Problemi correlati