Cifrado simétrico que involucra balanceadores de carga, ¿no puede aleatorizar la clave?

Question

Cifrado simétrico que involucra balanceadores de carga, ¿no puede aleatorizar la clave?

#1 de Maarten Bodewes (1 votos)
#2 de Keith (0 votos)
#3 de Sykobee (0 votos)

1

Estoy trabajando para cifrar la cookie de una aplicación web. Al usar AES / CBC simétrico, encripto los datos de las cookies antes de escribirlos, y luego los descifro cuando los vuelvo a leer: el material estándar.

El problema es que las personas pueden usar balanceadores de carga para hospedar esta aplicación web. Por esa razón, la clave secreta utilizada para cifrar los datos de las cookies no puede ser aleatoria: siempre debe ser la misma para que un servidor de equilibrio de carga pueda descifrar una cookie que fue escrita por otro servidor de equilibrio de carga.

Esto significa que mi clave secreta es mucho más fácil de descifrar que si la clave secreta fuera aleatoria. En este momento, uso "PBKDF2WithHmacSHA1" para derivar la clave secreta usando un salt no aleatorio. ¿Crees que eso es aceptable? ¿Hay alguna manera de hacerlo definitivamente más seguro en este caso? Gracias por sus ideas.

java aes cookies

pregunta Zoomzoom 28.08.2013 - 23:01

fuente

3 respuestas

Lea otras preguntas en las etiquetas java aes cookies

¿Cómo sabe Windows qué parte de la memoria está “destinada a contener solo datos”? ¿Es posible que un dispositivo habilitado para NFC emule una tarjeta Visa con PayWave?

score 1 · Answer 1

Los mecanismos estándar para hacer que el CBC sea más seguro es crear un IV aleatorio (uso en una cookie) y un código de autenticación de mensaje. Debe usar dos claves estáticas generadas aleatoriamente para esto. Usar un PBKDF no es una buena idea: si un atacante puede acceder al secreto, el juego termina, hagas lo que hagas. PBKDF ha sido diseñado para consumir ciclos de CPU, lo opuesto a lo que intenta hacer cuando se agrupan en clústeres para obtener rendimiento.

A menos que pueda diferenciar entre máquinas de clúster (tal vez haga una más segura que la otra), entonces agregar más seguridad será complicado.

score 0 · Answer 2

¿Qué te parece usar una clave secreta aleatoria y almacenarla en una base de datos u otra ubicación disponible desde todos los servidores?

En general, los equilibradores de carga se configuran de manera tal que las solicitudes posteriores que forman parte de la misma sesión van al mismo miembro del clúster: solo van a un segundo cuando falla el primario. Quizás pueda volver a crear la cookie cifrada (nueva clave secreta) en este caso (raro).

score 0 · Answer 3

Si la configuración del equilibrador de carga de su empresa hace lo no estándar de no bloquear las sesiones a los servidores, tiene varias opciones.

O bien mantiene las claves estáticas en todo el clúster (puede basarlas en algo que cambia, pero es consistente en todo el clúster, por ejemplo, información de la versión de la aplicación / de Maven).

O tienes que poner un mecanismo de sincronización para compartir los secretos.

Por ejemplo, ZooKeeper es un servicio de coordinación bastante simple de usar. Alternativamente, puede usar JMS para enviar un mensaje a los otros miembros del clúster con la clave.

O incluso podría usar JMX, con un mecanismo establecido, si su aplicación conoce a los otros miembros del clúster (clúster codificado o descubrimiento del servicio).

O incluso escriba su propia API de sincronización, un buen mecanismo de intercambio de claves entre los miembros del clúster.

Una vez que tiene instalado un sistema de coordinación, de repente puede generar nuevas claves y sales todo el tiempo, lo que es bueno (y recomendable).