Crittografia simmetrica che coinvolge bilanciamento del carico - chiave non casuale?

1

Sto lavorando alla crittografia dei cookie di un'applicazione web. Usando AES / CBC simmetrico, crittografo i dati dei cookie prima di scriverlo e poi decrittalo durante la lettura - le cose standard.

Il problema è che le persone possono utilizzare load balancer per ospitare questa app Web. Per questo motivo, la chiave segreta utilizzata per crittografare i dati dei cookie non può essere randomizzata, deve sempre essere la stessa in modo che un server di bilanciamento del carico possa decrittografare un cookie che è stato scritto da un altro server di bilanciamento del carico.

Questo significa che la mia chiave segreta è molto più facile da decifrare che se la chiave segreta fosse randomizzata. In questo momento io uso "PBKDF2WithHmacSHA1" per ricavare la chiave segreta usando un sale non casuale. Pensi che sia accettabile? C'è un modo per renderlo definitivamente più sicuro in questo caso? Grazie per i tuoi approfondimenti.

    
posta Zoomzoom 28.08.2013 - 23:01
fonte

3 risposte

1

I meccanismi standard per rendere CBC più sicuro è creare un IV casuale (uso in un cookie) e un codice di autenticazione del messaggio. Dovresti usare due chiavi statiche generate casualmente per questo. L'utilizzo di un PBKDF non è una buona idea: se un utente malintenzionato può accedere al segreto, il gioco è finito, indipendentemente da quello che fai. PBKDF è stato progettato per gestire i cicli della CPU, l'opposto di ciò che si sta tentando quando si esegue il clustering per le prestazioni.

A meno che tu non sia in grado di distinguere tra le macchine cluster (forse ne crei una più sicura dell'altra), aggiungere una maggiore sicurezza sarà complicato.

    
risposta data 29.08.2013 - 20:23
fonte
0

Come utilizzare una chiave segreta casuale e memorizzarla in un DB o in un'altra posizione disponibile da tutti i server.

Generalmente, i bilanciatori di carico sono configurati in modo tale che le richieste successive che fanno parte della stessa sessione vengano indirizzate allo stesso membro del cluster, ma solo quando il primario fallisce. Forse potresti ricreare il cookie crittografato (nuova chiave segreta) in questo (raro) caso.

    
risposta data 28.08.2013 - 23:06
fonte
0

Se l'impostazione di bilanciamento del carico della tua azienda fa la cosa non standard di non bloccare le sessioni sui server, allora hai diverse opzioni.

In entrambi si tiene le chiavi statiche nel cluster (li si può basare fuori qualcosa che cambia, ma consistente nel cluster - per la versione esempio di applicazione / informazioni Maven)

.

O devi mettere in atto un meccanismo di sincronizzazione per condividere i segreti.

Ad esempio, ZooKeeper è un servizio di coordinamento abbastanza semplice da usare. In alternativa, è possibile utilizzare JMS per inviare un messaggio agli altri membri del cluster con la chiave.

In alternativa si potrebbe anche utilizzare JMX, con un meccanismo di set, se l'applicazione è a conoscenza degli altri membri del cluster (grappolo hardcoded, o di individuazione del servizio).

O persino scrivere la tua API di sincronizzazione, un meccanismo di condivisione delle chiavi sicuro e protetto tra i membri del cluster.

Una volta che hai un sistema di coordinamento, puoi improvvisamente generare nuove chiavi e sali, il che è bello (e raccomandato).

    
risposta data 09.10.2015 - 18:57
fonte

Leggi altre domande sui tag