Asegurando la API REST con HMAC y autenticación básica

0

Me preguntaba si sería una buena idea ofrecer a los usuarios la elección de un método para asegurar su acceso a la API.

Background:

Estamos creando e implementando aplicaciones para nuestros clientes, lo que les ayuda a hacer su trabajo de manera más eficiente. Cada uno de nuestros clientes está ejecutando una aplicación autónoma y planeamos crear una API que les permita integrar sus herramientas de terceros o lo que sea. No será una API pública sino una privada.

Ahora, al investigar el tema llegué a comprender que el uso de autenticación básica, incluso a través de HTTPS, no es una muy buena idea. Aparentemente, el método preferido sería usar HMAC con nonces. Estoy a favor de asegurar el fuerte, sin embargo, la solución HMAC presenta un problema: es más complicado y requiere que el desarrollador cree primero HMAC y luego lo agregue a una solicitud, básicamente haciendo que la API no sea fácilmente detectable (como no puede escribir curl https://my.url/api/endpoint/ y ver que pasa).

Me llamó la atención que las personas en Stripe usen autenticación básica con token como usuario para que su solicitud de curvatura se vea así: curl -u sk_test_mysecretrandomkeywhatever https://my.url/api/endpoint/

Este es mi libro es una gran ventaja y, si es lo suficientemente bueno para la empresa de procesamiento de pagos, ¿quizás también lo sea para nosotros?

Entonces me puse a pensar: ¿qué pasa si ofrecemos ambas opciones? ¿Quieres usar autenticación básica solamente? Bien, solo puedes usar eso. ¿Uno de sus clientes es un fanático de la seguridad y quiere asegurarse de que su sistema esté seguro? Habilite la autenticación HMAC y comience a jugar con HMAC, etc. ¿Es esa una solución viable o diría que es una farsa de seguridad?

Por favor, arroje algo de luz sobre el tema o al menos apúnteme en la dirección correcta.

    
pregunta RandomWhiteTrash 02.09.2015 - 08:10
fuente

3 respuestas

5

No me queda claro qué tipo de problema está tratando de resolver y es posible que ni siquiera lo tenga claro. Si tiene una idea clara de lo que está tratando de lograr con la autenticación, no tendrá que ofrecerle al cliente múltiples esquemas de autenticación, sino que se quede con el que resuelve su problema.

Si teme que se comprometan las credenciales de autenticación porque la conexión podría ser detectada, simplemente use TLS. En este caso, la autenticación básica, las cookies de sesión o las autenticaciones similares en "texto claro" ofrecen suficiente protección, ya que el secreto está protegido durante la transferencia.

Si TLS no es posible, puede usar métodos de respuesta de desafío cuando tenga una clave secreta previamente compartida. Esto protege la autenticación pero no protege contra el secuestro de la conexión, es decir, un hombre en el medio podría pasar la autenticación y luego modificar cualquier acción realizada dentro de la conexión autenticada. Con el uso adecuado de TLS, esto no sería un problema, pero también podría usar métodos de autenticación más simples.

Hay otros métodos de autenticación (como la autenticación TLS mutua), pero le recomiendo que primero determine qué necesidades debe protegerse y contra qué tipo de uso indebido desea protegerse. Una vez hecho esto, puede seleccionar entre los métodos existentes el que mejor se adapte a su problema.

    
respondido por el Steffen Ullrich 02.09.2015 - 09:42
fuente
4

Bueno, el enrollamiento con autenticación básica es aceptable; recuerde que la sintaxis es enrollar - nombre de usuario: contraseña https://yoursite.com y esto significa que tendrá que ingresar credenciales de código en el código que invoca a su API REST, generalmente si es Ajax: entonces estamos hablando del código del lado del cliente y eso significa exponer las credenciales en el navegador (o en una aplicación móvil) que es una vulnerabilidad.

Creo que puedes mejorar con un enfoque de 2 pasos, que es una práctica bastante común:

Cuando el usuario inicia sesión (aplicación o navegador): obtenga un nombre de usuario / contraseña de un formulario y use curl con autenticación básica para pedirle al servidor un token de tiempo TOTP basado en una sola vez. No sé qué idioma está utilizando, pero en Node JS hay bibliotecas como esta https://github.com/guyht/notp que son proyectos activos y mantenidos.

Si está alojando en Azure, puede usar el acceso compartido SAS de Azure, que forma parte de la infraestructura de Azure, y guardar el código y la prueba.

    
respondido por el Danny Lieberman 02.09.2015 - 09:04
fuente
0

Pensándolo bien: una excelente manera de autenticar una API que expone la funcionalidad de sus sistemas a los socios es OAUTH2. Lo que es genial de OAUTH2 es que tiene una buena selección de bibliotecas, y puede usar un flujo que se adapte a su usuario relación: flujo del servidor, flujo del navegador web, flujo móvil, flujo de contraseñas sin cambiar su lógica de negocios API subyacente.

    
respondido por el Danny Lieberman 02.09.2015 - 12:44
fuente

Lea otras preguntas en las etiquetas