¿Hay alguna forma de aceptar solicitudes firmadas sin almacenar la contraseña del cliente en texto sin formato?

6

Estamos desarrollando el servicio web REST. Daremos identificador y cadena secreta a cada uno de nuestros clientes REST. Al realizar solicitudes, los clientes se autenticarán utilizando algoritmo HMAC (firmarán el cuerpo y los encabezados de las solicitudes HTTP utilizando la cadena secreta). El servicio REST recibirá encabezados HTTP, cuerpo, encuentra el secreto del cliente de la base de datos utilizando su Identificador, lo firma y comprueba si la firma calculada es igual a la firma proporcionada por el cliente.

En realidad, se explica mejor en autenticación de Amazon S3 página de documentación.

Para utilizar este esquema, tenemos que almacenar las claves secretas de los clientes en texto sin formato, ¿no?

¿Hay otra forma de autenticar a los clientes sin almacenar sus claves secretas en nuestros servidores (o almacenarlas de forma no recuperable, por ejemplo, sus hashes MD5)?

    
pregunta galymzhan 11.03.2011 - 12:01
fuente

3 respuestas

13

Estrictamente hablando, el uso del término "firma" sobre HMAC es incorrecto; está muy extendido, pero sigue siendo incorrecto: las firmas son sobre algoritmos asimétricos con una clave pública y privada, como RSA.

HMAC usa una clave secreta (es decir, un grupo de bytes arbitrarios) que se usa para calcular la MAC y para verificarla (en realidad se verifica al volver a calcularla). Entonces, en su problema, sí, el servidor debe almacenar la clave secreta o algunos datos que sean suficientes para recuperarla.

Tenga en cuenta que la clave secreta K se puede derivar de la contraseña de forma no invertible. P.ej. a través de una función hash o, mejor aún, con una Función de derivación de claves . El servidor almacenará la clave K "en texto sin formato" y conocer la clave K es suficiente para generar valores HMAC válidos. Sin embargo, esto obliga a un atacante a usar algún software específico para eso, no el cliente estándar que solicita una contraseña de usuario. Dependiendo del contexto y su modelo de ataque, esto puede o no ser una mejora de seguridad.

Una forma de lograr lo que está buscando, pero con una mayor complejidad que un HMAC simple, es utilizar SRP . SRP es un protocolo de intercambio de claves asimétricas con autenticación mutua basada en contraseña, con las siguientes características:

  • No es necesaria la distribución de claves públicas (PKI, certificados ...).
  • El cliente autentica el servidor y el servidor autentica al cliente, en el mismo paso, incluso en presencia de atacantes activos (los atacantes "Man-In-The-Middle" están derrotados).
  • Ningún atacante activo o pasivo aprende suficiente información para realizar ataques de diccionario sin conexión (un ataque de diccionario es adivinar la contraseña al intentar palabras aleatorias; el ataque está fuera de línea si se puede hacer sin interactuar con el honesto cliente o servidor para cada conjetura).
  • Lo que el servidor almacena no es suficiente para aprender la contraseña o hacerse pasar por el cliente (pero permite ataques de diccionario sin conexión, lo que es inevitable).

La clave que resulta del protocolo SRP se puede usar para un algoritmo MAC como HMAC. No necesita ser almacenado: solo se guarda en la memoria RAM durante la sesión.

SRP se puede integrar en TLS, como se explica en RFC 5054 . La forma más sencilla y estándar de usar SRP en su contexto sería usar HTTPS (es decir, HTTP dentro de un túnel SSL / TLS) con la parte TLS usando SRP para el intercambio de claves. GnuTLS es una implementación de código abierto de SSL / TLS que admite SRP.

    
respondido por el Thomas Pornin 11.03.2011 - 15:00
fuente
5

SRP no requiere un tercero de confianza o un certificado SSL porque usa el secreto compartido existente entre el cliente y el servidor para la autenticación. Un tercero no es necesario cuando las dos partes originales ya confían entre sí. Y a diferencia de los esquemas basados en HMAC, SRP almacena la contraseña en el servidor de una manera "no recuperable" o no de texto simple, lo que significa que un atacante que descubre el secreto del servidor no obtiene la capacidad de hacerse pasar por un cliente.

Otras ventajas de TLS-SRP sobre un esquema HMAC ad-hoc son: resistencia a ataques de diccionario fuera de línea, resistencia a ataques de repetición y encriptación de transporte.

    
respondido por el Tom Wu 13.03.2011 - 01:55
fuente
5

Como señaló Thomas Pornin, SRP / TLS es compatible con GnuTLS, y OpenSSL será compatible con los conjuntos de cifrado SRP en la versión 1.0.1. Los parches están disponibles para OpenSSL 0.9.8 y 1.0.0. Si su aplicación usa C / C ++, está bastante bien cubierto.

Para Java, hay BouncyCastle, y para Python, hay TLSLite. ¿Qué idioma y plataforma estás usando?

    
respondido por el Tom Wu 15.03.2011 - 22:25
fuente

Lea otras preguntas en las etiquetas