Al usar HMAC-SHA256, ¿debo guardar el secreto en la base de datos para verificar el remitente?

Question

Al usar HMAC-SHA256, ¿debo guardar el secreto en la base de datos para verificar el remitente?

#1 de David (1 votos)

1

Muchas API's encontré que usando el mismo método para la autenticación:

La firma es un mensaje codificado HMAC-SHA256 que contiene nonce, ID de cliente (se puede encontrar aquí) y la clave API. El código HMAC-SHA256 debe generarse utilizando una clave secreta que se generó con su clave API. Este código se debe convertir a su representación hexadecimal (64 caracteres en mayúscula).

enlace

Creo que para que funcione, el proveedor de servicios debe mantener en secreto una copia de la API, y luego puede verificar si el usuario usó el mismo secreto para generar la firma.

Estoy pensando que es muy inseguro, y es como almacenar una contraseña simple en la base de datos. Cualquier persona que obtenga una copia de seguridad de una base de datos antigua tiene los secretos de todos los usuarios.

¿Me estoy perdiendo algo? Existe un método para que el servidor verifique que el usuario haya codificado una firma utilizando un secreto específico, sin almacenar el secreto en la base de datos.

Debido a esto, creo que para proporcionar al usuario una clave privada de OpenPGP pair, y luego puedo validar la firma usando la clave pública.

¿Cree que hay un error de seguridad en la forma en que bitstamp funciona, por ejemplo, y OpenPGP sería mejor?

authentication rsa openpgp

pregunta Aminadav Glickshtein 14.01.2018 - 17:03

fuente

1 respuesta

Lea otras preguntas en las etiquetas authentication rsa openpgp

¿Qué tan seguro es mi sesión pero no apago luks HD Bajo HIPAA, ¿es posible recordar / almacenar las credenciales de los usuarios?

score 1 · Answer 1

HMAC-SHA256 es un código de autenticación de mensaje que utiliza un secreto compartido entre las dos partes que se comunican. Es absolutamente necesario que ambos extremos posean la misma clave (y cualquiera con esa clave puede generar y validar mensajes). Entonces, sí, su conclusión de que el proveedor de servicios todavía tiene la clave es una intuición correcta. (Podrían almacenar la clave o usar algún mecanismo para la regeneración determinista).

Un par de llaves asimétrico (siendo OpenPGP un ejemplo) evitaría esto, pero tiene una implementación mucho más compleja, más margen de error y mayores tiempos de cómputo en ambos extremos para las comunicaciones.

En el caso de que regeneren la clave HMAC, podría hacerse de una manera que dificultaría a un atacante robar la clave. Quizás calculen un HMAC(username, secret) utilizando un secret que se almacena en un HSM. Esto les permitiría generar de manera determinista la clave de la API sin necesidad de almacenarla de forma clara. Usar un HSM hace que sea muy difícil para un atacante robar el secreto necesario para generar claves por usuario.

La decisión sobre cuál es el adecuado dependería de varios factores, incluidos los requisitos de integridad necesarios para el servicio en cuestión. Tal vez el proveedor de servicios considere que el daño que haría una base de datos filtrada no empeora debido a que se incluyen las claves de la API. Si la información es mucho más valiosa o el sitio solo sirve para permitir la recuperación de información de esa base de datos, entonces el acceso a las claves de API agrega poco a la recompensa del atacante.