Tokens web JSON - ¿Cómo almacenar la clave de forma segura?

24

Estaba creando un servicio web RESTful cuando encontré los tokens web JSON como una alternativa a las cookies tradicionales para la autenticación. El concepto básico de este método es que el servidor es el único agente que conoce la clave secreta que se usa para digerir (comúnmente se realiza con HS256) la carga útil, de modo que solo él puede determinar si el cliente modifica o no el contenido del mensaje. Mi preocupación con este enfoque es: ¿Cómo puedo almacenar de forma segura la clave secreta utilizada por el servidor para cifrar la carga útil? ¿Debo cambiarlo periódicamente? ¿Debería generarlo 'al azar'?

Pensé en generar una cadena 'aleatoria' cuando mi servicio web RESTful se inicia y lo almacena en una 'variable global' utilizada después para digerir mis cargas útiles, por lo que temo la posibilidad de que otro proceso acceda al espacio de memoria de mi aplicación de descanso 'o que la función de memoria virtual de mi sistema operativo exponga o vulnere mi clave secreta.

Muchas gracias a todos

    
pregunta NMO 29.04.2015 - 14:56
fuente

1 respuesta

28

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.

    
respondido por el Tim X 01.05.2015 - 04:19
fuente

Lea otras preguntas en las etiquetas