Usar contraseña para calcular la suma de comprobación para solicitudes de API

Navega tus respuestas
3

Me preguntaba si sería una forma efectiva de asegurar una API al exigir que todas las solicitudes sean sumadas, con la contraseña del usuario (o una versión con hash). Con la protección me refiero a hacer que sea "imposible" para un tercero realizar solicitudes en nombre de otra persona o alterar el contenido. El contenido de la solicitud no sería privado.

Imagine una API que le permita a un usuario guardar un texto, luego la solicitud (que contiene la identificación del usuario, el texto, otra información) se incluiría junto con la contraseña del usuario que actúa como un secreto común y no codificado Un cliente y el servidor. El servidor luego verifica si la suma de comprobación es correcta y sabe que la solicitud no se ha modificado y se origina en ese usuario.

¿Es esto algo que se hace comúnmente y, si es una mala idea, por qué y qué se puede hacer en su lugar?

    
pregunta Samuel 10.01.2016 - 19:49
fuente

2 respuestas

1

El uso de un hash para la autenticación es muy razonable, pero es un poco difícil hacerlo bien. Debería usar una autenticación de mensajes basada en hash ya que evita algunas fallas sutiles. Puede encontrar bibliotecas acreditadas que lo admiten para la mayoría de los idiomas / plataformas.

Un inconveniente de esta estrategia es que requiere que el servidor tenga una copia de texto claro de la contraseña. Esto rara vez es recomendable para las contraseñas de los usuarios. Pero usarlo para generar secretos es muy útil.

Una forma de evitar el almacenamiento de contraseñas es requerir un paso de autenticación de nombre de usuario / contraseña (u otro) que devuelva un token seguro generado por el servidor. El cliente puede usar ese token para firmar y el servidor podría validarlo. Si el token es un HMAC de información clave del inicio de sesión, como nombre de usuario, tiempo de espera de sesión, etc., el servidor no necesita almacenar el token para verificarlo. Pero, en este punto, básicamente ha recreado OAuth y probablemente debería usarlo.

Todo esto supone que estás usando SSL. Sin eso, será muy difícil evitar MiTM, la reproducción y ataques similares.

    
respondido por el Neil Smithline 10.01.2016 - 20:40
fuente
2

Esto huele a homebrew con todos los problemas inherentes. HTTPS abordó muchos posibles ataques, incluidos los que describió. Será ingenuo suponer que usted / yo / {cualquier otra persona sola} puede encontrar mejores alternativas. A menos que dicho enfoque sea revisado por expertos de la comunidad de seguridad y se haya probado por tiempo.

El estándar HTTPS con autenticación fuerte resuelve todas sus preocupaciones.

    
respondido por el oleksii 10.01.2016 - 21:57
fuente

Lea otras preguntas en las etiquetas

Presencia de la tabla “sqlmapoutput” en la base de datos PostgreSQL Gmail twofactor auth en computadora no confiable