Ocultar HMAC-SHA256 en el código fuente y el archivo de configuración

Question

Ocultar HMAC-SHA256 en el código fuente y el archivo de configuración

#1 de Steffen Ullrich (2 votos)

0

¿Tendría sentido o proporcionaría una ventaja de las clases dividir una clave secreta HMAC-SHA256 en dos componentes y ocultar un componente en un archivo de configuración del lado del servidor aplicable y el otro componente en el código compilado (fuente cerrada, lado del servidor)?

Elegiría que ambas mitades sean lo suficientemente largas para que contengan la entropía suficiente para asegurar que, incluso si la otra mitad de la clave está comprometida, la otra mitad de la clave sigue siendo demasiado larga / compleja para ser forzada brutalmente. Por ejemplo, cada mitad son 32 bytes crypto-sudo-aleatorios que se concatenan para formar la clave secreta completa.

Entiendo que, en general, no se recomienda ocultar las claves secretas en el código fuente, ya que el código fuente es difícil de mantener en secreto, pero no puedo ver nada más que ventajas al emplear esto. Si la clave del código fuente es robada, la clave de configuración aún está oculta y es demasiado larga para ser forzada. Alternativamente, si un atacante logra robar la clave de configuración pero no conserva una copia de la clave del código fuente compilado, aún no pueden falsificar las firmas de tokens de JWT.

Por lo tanto, mi pregunta es: ¿Estoy exagerando una especie de falla obvia en este diseño o realmente proporciona al menos un poco mejor seguridad? Además, si no hay una falla obvia, ¿es razonable creer que esto realmente aumenta la protección de la clave secreta?

key-management jwt

pregunta dFrancisco 09.02.2018 - 20:26

fuente

1 respuesta

Lea otras preguntas en las etiquetas key-management jwt

¿Es posible detectar a alguien que se hace pasar por un dispositivo en mi red wifi? 1 vs 2 vías de filtro SSL + IP mutuo

score 2 · Accepted Answer

Según su descripción, esencialmente divide el secreto en varias partes y las coloca en diferentes ubicaciones. Y estas partes son lo suficientemente complejas como para que un atacante necesite encontrar todas las piezas para tener éxito, es decir, no es posible encontrar solo algunas partes y luego adivinar el secreto restante.

Si en este escenario, al menos una de estas ubicaciones está protegida con la misma fuerza con la que tradicionalmente protegería el secreto completo, este sistema de secreto dividido no es menos seguro en comparación con el sistema de secreto completo tradicional más seguro. Si, en cambio, piensa que al dividir las claves, el sistema se vuelve más seguro y le importa menos asegurar cada pieza de lo que le hubiera importado el secreto completo, entonces el sistema de clave dividida podría ser menos seguro.

Por su descripción, es imposible saber qué tan bien están protegidas las partes de los secretos. El código fuente puede ser robado dependiendo de lo bien protegido que esté, o el código puede ser diseñado por ingeniería inversa dependiendo de cuánto esfuerzo se haya realizado para ofuscar el secreto en el código. Similar a un archivo de configuración puede ser fácilmente accesible o no. Tampoco se sabe cuán crítico es realmente el secreto y cuánta protección necesita. Por ejemplo, en algunos casos de uso, tiene más sentido cambiar el secreto a menudo que invertir demasiado esfuerzo en la protección a largo plazo del secreto. Y un secreto que depende en parte del código fuente podría ser menos flexible en tales casos.