Il processo di crittografia dei dati è sicuro?

Question

Il processo di crittografia dei dati è sicuro?

#1 da (3 voti)

2

Ho creato il seguente processo di crittografia che userò per memorizzare le chiavi del CD all'interno del mio database. Prima di usarlo, tuttavia, devo assicurarmi che questo sia il più sicuro possibile.

Da quello che vedo, ci sono due preoccupazioni principali:

La memorizzazione della chiave privata deve essere estremamente sicura. Se qualcuno ottiene una sospensione della chiave primaria, possono decrittografare tutti i dati nel mio database
Il metodo di crittografia deve essere il più sicuro possibile

C'è un modo migliore per archiviare in modo sicuro i dati in questo scenario? In caso contrario, come posso garantire che questo processo sia il più sicuro possibile?

Ecco il mio codice:

public static function encrypt_key($key)
{
        $iv_size = mcrypt_get_iv_size(MCRYPT_CAST_256, MCRYPT_MODE_CBC);
        $iv = mcrypt_create_iv($iv_size, MCRYPT_RAND);
        return $iv . openssl_encrypt ($key, 'AES-256-CBC', '32 bit private key', 0, $iv);
}

public static function decrypt_key($key)
{
        $iv_size = mcrypt_get_iv_size(MCRYPT_CAST_256, MCRYPT_MODE_CBC);
        $iv = substr($key, 0, $iv_size);
        return openssl_decrypt(substr($key, $iv_size), 'AES-256-CBC', '32 bit private key', 0, $iv);
}

php cryptography encryption

posta dspacejs 19.07.2015 - 11:27

fonte

1 risposta

Leggi altre domande sui tag php cryptography encryption

Quanto è pericoloso usare textmods da fonti internet? Website Spam Bot in Google Analytics

score 3 · Accepted Answer

Ci sono diversi miglioramenti che possono essere apportati alle funzioni che hai fornito, in base alle mie conoscenze.

Minacce ovvie

Per prima cosa, e soprattutto, mantieni sicura la tua chiave privata e rendila esterna alla definizione della funzione (ad esempio, un secondo argomento). Consiglierei di spendere sforzi significativi per risolvere questo problema. Questa è la crittografia per utente o la crittografia a livello di applicazione? Se è per utente, allora perché non utilizzare un algoritmo di derivazione della chiave, come PBKDF2 ? Se è un'applicazione, quindi buona fortuna con l'archiviazione sicura, ci ho pensato prima, e sembra non banale per una tipica app web. Assicurati che non memorizzi la chiave privata insieme all'origine, né (ovviamente) nello stesso database .

Inoltre, per inciso: non usare mai la crittografia simmetrica per tutto ciò che è simile a una password. Utilizzare invece un hash unidirezionale. Suppongo, per questa risposta, che tu debba effettivamente recuperare la chiave del CD originale, invece di verificare una corrispondenza.

In secondo luogo, sono dubbioso sull'uso di MCRYPT_RAND. Sembra che potrebbe essere lo stesso PRNG di rand () , che non è l'ideale. Generare IV con MCRYPT_DEV_URANDOM è ciò che raccomanderei - / dev / random e / dev / urandom sono entrambi considerati fonti di prim'ordine di numeri casuali crittografici su sistemi basati su Unix. Nota che non generalmente vuoi usare / dev / random per un'applicazione web, perché aprirebbe un semplice vettore DoS - e / dev / urandom dovrebbe essere sufficiente al di fuori degli ambienti embedded, comunque.

Altri problemi di implementazione

Ora, con le principali vulnerabilità che posso individuare, alcuni dettagli a grana fine:

Stai mescolando le funzioni OpenSSL e mcrypt. Inoltre, openssl_encrypt non è documentato nei documenti PHP ufficiali (ho il sospetto che sia documentato per C da qualche parte, anche se ...). Potrebbe essere preferibile utilizzare mcrypt_encrypt invece, poiché è esplicitamente documentato per PHP.

Stai mixando anche CAST-256 e AES-256. Dovresti probabilmente rimanere con AES-256 per tutto il tempo, dal momento che questo è l'algoritmo standard generalmente consigliato per una strong crittografia simmetrica. Tieni presente che AES-256 è MCRYPT_RIJNDAEL_128 utilizzato con una chiave a 256 bit , e NON è uguale a Rijndael-256, che è qualcosa che non avevo mai realizzato prima (più sai!).

Non sono sicuro della modalità di crittografia preferita, ma CBC è uno che ho visto raccomandato per AES, almeno. Speriamo che qualcun altro abbia qualche input.