Autenticación con certificado de cliente vs HMAC

Creo que lo resumiste bien.

Algunos puntos adicionales más allá de la seguridad técnica de estas soluciones:

• Los certificados TLS requieren administración, expiran, etc. Debe considerar si tiene los recursos (puede automatizar hasta cierto punto) la administración de certificados. Un escenario bastante malo es cuando las operaciones de TI simplemente se hartan de todos los problemas y deshabilitan la validación de certificados porque de esa manera simplemente funciona . ;)

• Una implementación de la firma HMAC-SHA1 también es razonablemente buena y puede limitar la ventana de tiempo de una repetición (y como dijo, en TLS está bien). Sin embargo, la implementación es más compleja que la otra también. Si es un equipo más grande el que mantendrá el código y, especialmente, si a veces tiene que cambiar la implementación, es muy probable que se presente una falla. Los otros dos son mucho más simples en términos de código fuente que deben escribirse.

• HTTP Basic es muy simple y puede estar bien con TLS, pero como dijiste, diría que es el menos seguro de los tres. Muchas personas aún piensan que es lo suficientemente bueno para muchos propósitos, sin embargo, depende de lo que quieras proteger. TLS se considera seguro contra los atacantes MitM. Creo que la mayor ventaja es la simplicidad, no hay mucho que desviarse.

Para mí, es una obviedad: certificados TLS del lado del cliente . Son los más rápidos, más seguros, menos homebrew y usted dice que ya está utilizando las bibliotecas TLS . También son bastante más simples que la opción HMAC en términos de implementación.

No haga cosas de infraestructura de clave pública (PKI): simplemente deje que el lado del cliente genere un certificado autofirmado válido por 100 años y se marque como no CA. Confíe en ese certificado en el servidor. No hay razón para hacer PKI, YAGNI ... No resuelve su problema, presenta problemas de CRL o OCSP, clase de problemas SHA1 y muchos otros efectos secundarios. Piense en un certificado autofirmado como simplemente una clave pública RSA; de hecho, es una.

Asegúrese de que tanto el cliente como el servidor realicen sesiones TLS en caché. Esto te dará las conexiones TLS más rápidas. (Se beneficia de esto al tener solo certificados del lado del servidor. Se beneficia dos veces cuando agrega certificados del lado del cliente).

Hay muy poca programación con esto, solo se necesita implementar opciones de configuración textual simples que pasen algo de texto (como la ubicación de un archivo de almacén de confianza para usar). El personal administrativo hace el resto. También pueden probar cosas con openssl s_client etc.

Cualquier vulnerabilidad futura puede manejarse administrativamente (por ejemplo, a través de openssl ugprade o JDK upgrade).

La solución HMAC es una caja negra para administradores. Cualquier problema debe ser resuelto por los programadores.

Con la autenticación básica HTTP, estás haciendo un trabajo extraño. Usted aún necesita implementar TLS y configurar certificados X509 (por ejemplo, el cliente probablemente confiará en otra cosa que no sean las CA públicas predeterminadas) y aún necesita administrarlo y actualizarlo. Pero haces la mitad del trabajo y para la otra mitad utilizas un mecanismo completamente diferente. Parece válido, pero tiene un poco de mal olor.

Creo que sus suposiciones son correctas siempre y cuando tenga una política estricta de que el cliente finalice la conexión en caso de que no se pueda verificar la cadena de confianza del certificado del servidor o de que surja cualquier otro problema de seguridad de TLS. Si confía en el TLS, entonces está seguro contra repeticiones, etc.

Sin embargo, podría pasar un par de pensamientos sobre la pregunta de qué tan rápido puede reaccionar si se compromete su información de autenticación. En este caso, cambiar a una clave compartida puede ser significativamente más fácil o más difícil en comparación con poner un certificado de cliente en una CRL, esto depende completamente de su entorno. Mientras que TLS proporciona una buena protección para la transmisión de datos a través del cable, las opciones que describe podrían proporcionar un nivel diferente de comodidad / confiabilidad / seguridad cuando se trata de revocar la información de autenticación.