La realidad es que otros procesos pueden acceder a la memoria de proceso o a las funciones de su
Máquina virtual, el juego probablemente haya terminado ya que ya estás comprometido. Si un proceso
tiene acceso a este nivel, es probable que pueda obtener otra información, como la inicial
credenciales utilizadas para autenticar antes de obtener el token o simplemente modificar
los resultados para que la verificación de token se devuelva verdadero a pesar del resultado de verificación real
etc. No te concentres demasiado en las posibilidades extremas. La mayoría de los compromisos se producen a través de
Explotaciones mucho más simples o errores de configuración, como el almacenamiento de la clave privada en el
Sistema de archivos que es legible para todo el mundo y accesible para su servidor web, etc.
La mejor manera de administrar claves y secretos dependerá un poco de su plataforma. Algunos
plataformas proporcionan marcos de gestión clave y tal vez el uso de uno de ellos sería
apropiado.
No te concentres demasiado en el hecho de que esta es una clave secreta. En realidad, no es más
crítico que otras credenciales que necesita para administrar. Por ejemplo, ¿cómo se maneja?
¿Las credenciales que le permiten acceder a sus bases de datos? Si esa solución es suficientemente buena
para sus bases de datos, entonces probablemente sea lo suficientemente bueno para su clave secreta. Si no lo es
entonces me preguntaría si es realmente lo suficientemente bueno para su base de datos. La realidad
Es decir, si alguien va a comprometer el sistema, entonces es probable que lo estén haciendo.
para acceder a los datos / servicios que proporciona la interfaz. En la mayoría de los casos,
Este servicio o base de datos subyacente también necesita credenciales y administración de credenciales.
y estas son las verdaderas llaves del reino.
Creo que es mejor utilizar un enfoque coherente para administrar todas las credenciales que
necesidades de la aplicación y no tratar la clave secreta para la creación / verificación de tokens como
extra especial. No piense demasiado en la solución simplemente porque involucra palabras como
'clave' o 'secreto'. Todas las credenciales son datos confidenciales que deben gestionarse en una
Manera segura. Una gran parte de los errores que se cometen se deben a
sobre soluciones complejas de ingeniería que se vuelven difíciles de mantener y fáciles de obtener
incorrecto. Considere soluciones que utilizan instalaciones / marcos existentes, conocidos y probados,
como keytool , administradores de cadenas de claves, etc. Si falla, use algo que pueda ser
Fácil de entender y mantener. Algo tan simple como una base de datos puede ser
suficiente. Evite soluciones que impliquen almacenar la información como constantes o
variables globales, ya que esto puede ser difícil de mantener porque cambiar la clave
ahora significa un cambio de código y ahora tiene que probar, hacer la gestión de cambios y promover para
producción, etc.
En cuanto a cómo se generan las claves, dependerá de su entorno y de la
Tipos / niveles de riesgos que necesita gestionar. Como regla general, siempre estoy muy preocupado por
Cualquier cosa que se base en 'random'. Generar verdaderos valores aleatorios es extremadamente
Difícil ya menudo no hace nada para mejorar la seguridad. De hecho, los supuestos de
La aleatoriedad que luego ha demostrado no ser aleatoria puede revelar patrones, que en
a su vez, significa la posibilidad de poder predecir valores futuros, que es casi
Siempre es algo malo cuando hablas de llaves. En este escenario, no creo.
la aleatoriedad te va a ganar mucho desde una perspectiva de seguridad a menos que estés en una
entorno donde es crítico que los administradores de sistemas no conozcan la clave. Igualmente,
Es poco probable que el cambio regular de la clave proporcione mucho más que inconvenientes para
tus usuarios Cada vez que cambies la clave, todos los tokens emitidos actualmente se convertirán en
inválido. Es posible que desee considerar tener una política para cambiar la clave cuando el personal
dejar o cambiar roles e incluso podría considerar una política para cambiar la clave cada vez que
el software está actualizado, etc.
Sin embargo, cambiando religiosamente la clave cada semana más o menos
es poco probable que proporcione algo con respecto a la seguridad.
Tenga en cuenta que lo anterior no es válido para todas las teclas. Hay situaciones donde un
la clave privada debe gestionarse con sumo cuidado, por ejemplo, la clave privada para
raíz CA. No todas las teclas son iguales. Su enfoque de gestión debe coincidir con el
Requisitos y riesgos contra los que debe protegerse. En el caso de JWT, eres
tratar con un ecosistema en gran parte cerrado: la clave se utiliza para generar / firmar y verificar
tokens El objetivo es detectar la manipulación, no proteger el secreto. los
El riesgo es que si alguien obtiene la clave, puede crear tokens falsificados y ganar
Acceso no autorizado a su servicio. Lo que esto significa en última instancia depende de la
Servicio. La medida en que alguien intentará hacer esto también depende de la
Servicio subyacente y su valor percibido. La longitud a la que se dirige para asegurar la llave.
Debe reflejar la amenaza.