La crittografia RIJNDAEL è sicura da utilizzare con piccole quantità di testo fornite agli utenti?

Question

Sto pensando di passare alla memorizzazione dei dati di sessione in cookie crittografati piuttosto che da qualche parte sul mio server. Mentre ciò comporterà una maggiore larghezza di banda utilizzata per ogni richiesta, risparmierà il carico extra del server di database e lo spazio di archiviazione.

In ogni caso, ho intenzione di cifrare il contenuto dei cookie utilizzando RIJNDAEL 256.

function encrypt($text, $key) 
{ 
    return mcrypt_encrypt(MCRYPT_RIJNDAEL_256,$key,$text,MCRYPT_MODE_ECB,mcrypt_create_iv(mcrypt_get_iv_size(MCRYPT_RIJNDAEL_256,MCRYPT_MODE_ECB),MCRYPT_RAND)); 
} 

che nell'uso produrrebbe qualcosa come questo (base64 codifica per la visualizzazione)

print base64_encode(encrypt('text', 'key')); 

7s6RyMaYd4yAibXZJ3C8EuBtB4F0qfJ31xu1tXm8Xvw= 

io non sono preoccupato su un singolo cookie degli utenti che viene compromesso tanto quanto temo che un utente malintenzionato possa scoprire key e sia in grado di costruire qualsiasi sessione per qualsiasi utente poiché sanno cosa Io uso per firmare i dati.

Esiste un modo per verificare i tempi di fessurazione stimati in relazione ai parametri utilizzati? O esiste una misura standard di tempo in relazione alla dimensione del testo o della chiave utilizzata?

Ho sentito qualcuno dire che i tasti necessari per superare 256 bit stessi sono abbastanza sicuri da essere utilizzati con RIJNDAEL. Mi chiedo anche se la lunghezza del testo crittografato deve essere una certa lunghezza in modo da non dare via la chiave.

I dati saranno generalmente di circa 200 caratteri

a:3{s:7:"user_id";i:345;s:5:"token";s:32:"0c4a14547ad221a5d877c2509b887ee6";s:4:"lang";s:2:"en";} 

Quindi questo è sicuro?

Answer 1

Evitare l'uso di BCE. Può rivelare informazioni su ciò che è crittografato. Qualsiasi due blocchi con lo stesso testo in chiaro avrà lo stesso testo cifrato. CBC lo eviterebbe, ma richiede che un IV venga generato o salvato.

Evitare semplicemente di salvare una chiave e IV. Genera una chiave master a 256 bit utilizzando un generatore di numeri casuali crittograficamente forte e salvalo nell'applicazione in un posto sicuro. Usalo per generare le chiavi di sessione da utilizzare nella crittografia. La IV può essere derivata dalla chiave di sessione. Quando si genera la chiave di sessione, includere tutti i dati disponibili che possono essere utilizzati per restringere l'ambito della chiave di sessione. (per esempio.includere l'ambito il cookie, l'indirizzo host remoto, un nome casuale memorizzato con i dati crittografati e/o un ID utente se non rientra nei dati crittografati)

A seconda del modo in cui i dati devono essere utilizzati potrebbe dover includere un MAC. ECB e CBC non sono progettati per rilevare eventuali modifiche al testo cifrato e tali modifiche comportano l'eliminazione dei rifiuti in testo normale. Potresti voler includere un HMAC con i dati crittografati per permetterti di autenticarlo prima di prenderlo come canone. Una chiave HMAC di sessione deve essere derivata dalla chiave di crittografia di sessione. In alternativa, è possibile utilizzare la modalità PCBC. PCBC è stato creato per rilevare le modifiche nel testo cifrato, ma la sua capacità di farlo è limitata dalla dimensione del padding, che dipende dai dati crittografati e non tutte le API crittografiche lo avranno come opzione.

Una volta arrivato al punto di includere un MAC, è necessario prendere in considerazione l'adozione di misure contro gli attacchi di riproduzione. Ogni volta che qualcuno può inviare di nuovo i vecchi dati nell'ambito di una sessione è una possibilità per un attacco di riproduzione. Rendere l'utilizzo della chiave di sessione il più stretto possibile senza causare problemi all'utente è un modo per contrastare gli attacchi di riproduzione. Un'altra cosa che potresti fare è includere data e ora nei dati crittografati per creare una finestra mentre i dati devono essere considerati validi.

In estate, proteggere la chiave è solo la punta dell'iceberg.

Answer 2

Rijndael è stato rinominato AES. Sì, è sicuro da usare.

Detto questo, è necessario considerare attentamente ciò che si inserisce nel cookie. Dipende da ciò che hai a disposizione nel modo di storage sul tuo sistema, ma puoi semplicemente scegliere un numero casuale (ad esempio un numero a 64 bit) e memorizzarlo nel cookie. Nel tuo sistema lato server, dovresti tenere un registro di chi è stato associato a quel numero e gli altri dettagli. Questo evita del tutto la crittografia. Utilizzi gli altri dettagli per convalidare (nella misura in cui tutto può essere convalidato) se il cookie è stato rinviato dal browser in cui l'hai originariamente inviato.

In alternativa, è possibile utilizzare una chiave di crittografia diversa per ogni sessione, mantenendo una traccia di quale chiave è stata utilizzata con quale sessione.

Anche se si utilizza la crittografia diretta con una chiave fissa, considerare di includere un numero casuale con i dati da crittografare - questo rende più difficile craccare utilizzando un attacco in testo normale noto perché, per definizione, il numero casuale può essere " essere conosciuto

Answer 3

AES-128 dovrebbe essere più che sufficiente, senza necessità di utilizzare chiavi più lunghe - se la chiave viene scelta in modo casuale.

Tuttavia ci sono altri problemi. Il primo è che non dovresti usare la BCE. Con ECB un determinato blocco di testo in chiaro a 128 bit esegue sempre lo stesso testo cifrato a 128 bit nello stesso modo. Ciò significa che gli avversari possono modificare chirurgicamente il testo cifrato iniettando diversi blocchi per i quali conoscono il testo cifrato corrispondente. Ad esempio potrebbero mescolare i dati di due utenti diversi. Con altre modalità, CBC ad esempio va bene, il testo cifrato dipende anche dall'IV (vettore di inizializzazione), che dovrebbe essere diverso ad ogni esecuzione dell'algoritmo. In questo modo, lo stesso testo in chiaro viene cifrato in modo diverso ogni volta e l'avversario non può ottenere alcun vantaggio. È inoltre necessario salvare l'IV da qualche parte con il testo cifrato, senza necessità di proteggerlo. Ogni volta che la possibilità di riutilizzare la stessa IV diventa non trascurabile dovresti anche cambiare la chiave.

Il secondo problema è che è necessario aggiungere anche un codice di autenticazione del messaggio. Altrimenti non saresti in grado di distinguere i biscotti contraffatti da quelli buoni.

Answer 4

Se si utilizza una chiave lunga, direi che la chiave era abbastanza sicura. Alcune cose di cui preoccuparsi:

Si sta scaricando l'archiviazione dei dati sul client. NON FIDARE MAI DEL CLIENTE. Questo non significa che non puoi farlo, solo che devi trattare i dati nel cookie come non affidabili (non prendere decisioni più serie rispetto a 'tema' per mostrare all'utente basato su di esso) o fornire per un modo per convalidare i dati.

Alcuni esempi di come convalidare i dati sarebbero a:

• includono un sale (in modo che le persone con gli stessi dati di sessione non ottengono lo stesso cookie) e
• un checksum (così che qualcuno che cambia anche solo un bit del cookie lo rende inutile).

Answer 5

Sì Rijndael (AES) è sicuro, tuttavia l'implementazione è lungi dall'essere sicura. Ci sono 2 problemi in sospeso con la tua implementazione. L'uso della modalità ECB e IV è una variabile statica che verrà utilizzata per tutti i messaggi. An IV must always be a Cryptographic Nonce. Il tuo codice è in chiara violazione di CWE-329.Modalità BCE

non dovrebbe mai essere utilizzato, modalità CBC deve essere usato e questo perché:

originale:

criptata con la modalità BCE:

criptato utilizzando la modalità CBC: