¿HTTP Digest + MD5 sigue siendo una alternativa para consumir mi propia API?

4

Estoy leyendo mucho sobre la implementación de restricciones de seguridad en una API REST.

Hay muchos métodos, algunos mejores que otros para aplicaciones de 3party o para consumir mi propia API.

  • HTTP Basic + TLS (con claves)
  • HTTP Digest + TLS
  • OAuth 1.0a, 2.0
  • Application-only-auth (con claves) link
  • Amazon Signature Versión 4 Enlace

Para consumir mi propia API, tengo 3 opciones (de bajo a alto grado de dificultad para implementar, ¡siempre utilizando TLS!):

  1. HTTP Basic + TLS (con claves)
  2. HTTP Digest + TLS
  3. Application-only-auth (con claves)
  4. Amazon Signature Version 4

El único beneficio del resumen sobre Basic + tls es que la contraseña no se transfiere en texto sin formato sino en un hash MD5.

Pero de acuerdo con kbcert y wikipedia dicen que no se debe usar MD5 (ataques de colisión).

Mi pregunta es: si la seguridad de MD5 se ve comprometida (hoy y en un futuro próximo) 2. HTTP Digest + TLS no es una opción viable para consumir mi propia API y solo tengo otras opciones "más" seguras (1, 3, 4)?

Sé que HTTP Basic + TLS puede tener ataques de reproducción.

    
pregunta Diego Alvarez 11.10.2013 - 17:30
fuente

2 respuestas

5

Los ataques de colisión no son relevantes para el uso de una función hash en la autenticación "Digest"; ese utiliza la resistencia de preimagen para la cual MD5 es todavía bastante resistente.

Tenga en cuenta que siempre que use SSL / TLS (es decir, HTTPS), puede usar la autenticación básica: la capa SSL garantiza que la contraseña no se traslade "como texto no cifrado", y también que se envíe solo al servidor adecuado. . También tenga en cuenta que sin SSL / TLS, tiene otros problemas más allá de la autenticación, por ejemplo, secuestro hostil de la conexión después de la fase de autenticación. Para una seguridad razonable, realmente necesita SSL, y una vez que tenga SSL, entonces la autenticación básica está bien.

De hecho, la autenticación Digest introduce problemas adicionales, no debido a MD5, sino porque obliga al servidor a tener una copia de la contraseña; por lo tanto, el servidor debe almacenar las contraseñas "tal como están", y cualquier falla local de solo lectura en el servidor se vuelve crítica. Con la autenticación básica, el servidor solo necesita almacenar las contraseñas de hash (con un función de hashing de buena contraseña ), y eso es mucho mejor.

Así que no uses Digest, usa Basic. Pero no es una cuestión de "debilidad MD5"; El resumen con SHA-256 no sería mejor.

En cuanto a OAuth, su uso principal es delegar la autenticación, lo que puede ser o no una buena idea en su caso, pero es otra cuestión.

    
respondido por el Thomas Pornin 11.10.2013 - 17:37
fuente
0

Es tu modelo de amenaza para determinar. La autenticación básica es un buen candidato si tiene un sistema que verifique la contraseña y el punto final expuesto.

El nombre de usuario y la contraseña en la forma básica deberían funcionar bien con TLS si confía en que sus certificados sean seguros y su punto final no esté comprometido. Si está comprometido, el intruso puede desviar las contraseñas de texto simple de las solicitudes.

El método de Amazon es el mejor. Puede delegar la comprobación de firmas en sistemas seguros que conozcan la clave. Si el punto final está comprometido, no pierde las contraseñas porque nunca se envían en la solicitud.

No sé digerir lo suficientemente bien. No se usa mucho.

    
respondido por el Jonathan 11.10.2013 - 21:27
fuente

Lea otras preguntas en las etiquetas