Diferencia de seguridad entre tokens web y firma de mensajes

1

Estoy viendo dos tipos diferentes de autenticación ampliamente utilizados, uno de los cuales es mucho más complejo que el otro. Uno son los tokens de identificación de sesión simples que se utilizan en la mayoría de los sitios web (el usuario envía información de inicio de sesión, recibe un token y lo pasa con cada solicitud futura como autorización). La otra es la firma HMAC utilizada en algunas API (usa claves públicas / privadas para la codificación de mensajes).

Desde el exterior, el método HMAC parece mucho más seguro. Los mensajes no pueden ser falsificados ni duplicados, sabe que el mensaje siempre es auténtico. Sin embargo, requiere mucho más trabajo para empaquetar y registrar cada solicitud, y requiere una forma para que el cliente obtenga acceso a las claves públicas / privadas que se utilizan para la firma.

Por contrato, los tokens han existido por mucho tiempo, y parecen ser relativamente seguros si se usan correctamente (solo se transmiten por SSL, se pasa un token nuevo con cada respuesta del servidor, se registra el último token utilizado, etc.), y no requieren ningún manejo de claves.

Entonces, ¿por qué existe la firma HMAC en la web? ¿Hay escenarios que los tokens de sesión simples no puedan proteger? Si es así, ¿por qué se siguen utilizando los tokens?

Los tokens son mucho más fáciles de diseñar para clientes ligeros cuando no tengo que encontrar una forma de pasar las llaves, pero tampoco quiero dispararme a mí mismo al pasar por alto los agujeros de seguridad inherentes. / p>     

pregunta Nairou 24.10.2017 - 17:59
fuente

1 respuesta

1

Los tokens firmados son útiles en la situación en la que hay una separación entre el servidor que inicia sesión y el servidor que proporciona el servicio. El servidor que inicia sesión le proporciona un token, firmado con su clave privada. El servidor que proporciona el servicio no necesita conocer esa clave, puede verificar con la clave pública del servidor de inicio de sesión para asegurarse de que sea válida.

Las sesiones simples son excelentes para las configuraciones de un solo servidor, pero pueden ser más difíciles de escalar (aunque no es imposible en ningún caso), ya que la identificación de la sesión debe consultarse en el lado del servidor para validarla: una identificación de sesión es válida Si y solo si está en la lista de sesión activa del servidor. Eso significa que si se crea una sesión en un servidor, es necesario que haya un trabajo adicional para que un servidor independiente lo reconozca. Existen marcos para sesiones entre servidores, pero no es el predeterminado en la mayoría de los casos.

Si haces tokens, debes asegurarte de que todos los tokens que aceptas estén firmados adecuadamente y de que compruebes que son exactamente como esperas. Ha habido algunas vulnerabilidades señalado eso sucede cuando no está rígido con respecto a los algoritmos que acepta en su sitio; debe ir más allá del estándar JWT y en realidad aplicar su propio estándar más estricto en general. (No estoy de acuerdo con la conclusión de ese artículo, pero debes tenerlo en cuenta si haces JWT o tokens similares)

    
respondido por el crovers 24.10.2017 - 19:40
fuente

Lea otras preguntas en las etiquetas