Un código de autenticación de mensaje adecuado para REST

Si usa SSL para el transporte, y lo hace correctamente, entonces cualquier MAC adicional es redundante; y, cuando se trata de eso, también lo es SCRAM . Un punto de venta de SCRAM es que se supone que debe resistir situaciones en las que se utiliza SSL incorrectamente , es decir, sin la autenticación apropiada del servidor (desafortunadamente, sucede ). Pero el argumento de seguridad de SCRAM es bastante débil en tal situación, porque no impedirá que un man-in- el ataque medio ; y, sin un MitM, la contraseña simple básica dentro de SSL ya es buena. La única ventaja de SCRAM sobre una contraseña simple es que, en caso de un MitM, el atacante no aprende la contraseña de inmediato. Todavía ve todos los datos intercambiados, puede insertar sus propios comandos y obtiene suficientes datos para realizar un ataque de diccionario sin conexión , algo de lo que muy pocas contraseñas vienen ilesas.

En su propuesta para agregar un MAC, no dice de dónde proviene la clave de MAC. Esto es crítico. Un MAC tiene cualquier valor solo mientras la clave sea desconocida para el atacante. Pero si el cliente y el servidor ya comparten una clave desconocida para el atacante, ¿por qué se molestarían con una contraseña y SCRAM? Permítales usar Clave precompartida TLS , es decir, SSL / TLS con la clave compartida como base para la autenticación y el cifrado mutuos: no certificado en absoluto (por lo que no hay validación de certificado para equivocarse), operación astuta y rápida

Aún mejor, si el cliente y el servidor comparten una contraseña, no quieren usar certificados, temen los ataques del diccionario sin conexión, y no quieren que el servidor almacene las contraseñas tal como están, entonces la solución es TLS-SRP . El cliente y el servidor se autentican entre sí con respecto a una contraseña común, el servidor no almacena la contraseña sino solo un equivalente de hash de la misma, y la contraseña está a salvo de los ataques del diccionario sin conexión, incluso en caso de un intento MitM (no solo se frustra el intento, sino que el atacante ni siquiera obtiene datos suficientes para "probar las contraseñas en casa").

Los diseñadores de SCRAM probablemente recibieron información sobre SRP en algún momento, porque agregaron en la sección 9 de la especificación el siguiente párrafo:

  

Los mecanismos de autenticación que protegen contra este ataque son      disponible (por ejemplo, la clase de mecanismos EKE). RFC 2945 [RFC2945] es      Un ejemplo de tal tecnología. El WG eligió no usar EKE como      Los mecanismos como base para SCRAM.

No dan ninguna justificación de por qué rechazan los protocolos de PAKE (que denominan de forma incorrecta "EKE", que es solo el nombre del primer protocolo PAKE conocido).

Para la mayoría de las configuraciones, te recomiendo que uses solo tokens HTTPS (SSL) y CSRF. Esta es la arquitectura estándar para asegurar una aplicación web / servicio web. Si usa tokens HTTPS + CSRF, no necesita un MAC.

Me gustaría rechazar la idea de "usar SSL solo para las cosas sensibles". Eso tiene algunos problemas. Recomendaría usar HTTPS en todo el sitio. Busque en este sitio información sobre las ventajas y desventajas de usar SSL en todo el sitio y cómo implementarlo.

No sé si su interfaz es solo para uso programático o si también será utilizada por humanos. Si es así, HTTPS probablemente también proporcionará la mejor facilidad de uso para los usuarios, si el lado del cliente tiene un humano sentado detrás de un navegador web.