Esquema de autenticación web personalizado

5

Para un proyecto en el trabajo, actualmente estoy implementando un servicio web no demasiado grande. Por razones de aprender algo nuevo, intenté convertirlo en un servicio REST, que luego provocó el problema de la autenticación. Finalmente me decidí por la Autenticación básica de HTTP, ya que tiene la ventaja de ser compatible con prácticamente cualquier biblioteca HTTP, aunque yo mismo tuve que implementar el lado del servidor.

Ayer, un colega me sugirió que simplemente enviara la contraseña con hash en lugar del nombre de usuario y la contraseña (eventualmente, solo se podrá acceder al servicio a través de HTTPS, por lo que consideré que la Autenticación básica no es un problema de seguridad, pero dejemos eso de lado por ahora). ). Pero me pregunté qué cambiaría realmente, en cuanto a seguridad.

Enviar la contraseña con hash básicamente significa un hash bcrypt, ya que eso es lo que almacenamos en la base de datos. Lo que significa que primero tendría que enviar al cliente el factor de trabajo y sal para que puedan llegar al mismo hash que tengo en la base de datos. Esto requiere un mecanismo de desafío-respuesta que ya es mucho más complicado de implementar.

Luego está el punto de que la contraseña con hash que el cliente envía para la autenticación funciona esencialmente como una contraseña de texto sin formato, en lo que respecta a la autenticación; y podría ser reproducido fácilmente, si alguien lo toma.

Básicamente, lo que encontré:

  • resuelve enviando la contraseña en un formato simple, similar a Digest, a diferencia de Basic
  • no resuelve el problema de la repetición (el Compendio lo hace, debido al uso de un nonce) de Basic
  • Requiere hash de contraseña en el cliente con un rendimiento menos predecible. P.ej. Es probable que los teléfonos inteligentes requieran factores de trabajo más pequeños que las máquinas de escritorio y los principales consumidores de la API serían los teléfonos inteligentes y las tabletas. Entonces tendríamos que reducir la fuerza de bcrypt en ese caso.
  • Sería mucho más complejo de implementar, tanto en el cliente como en el servidor, debido a un esquema personalizado de desafío / respuesta y, por lo tanto, más espacio para errores. Probablemente también va en contra de los principios REST.

¿Me perdí algo? HTTPS resuelve los problemas de la autenticación básica, hasta donde entendí y, por lo tanto, el esquema personalizado no resuelve ningún problema real, aparte del aburrimiento del desarrollador, tal vez. Pero no soy un experto en nada de esto.

    
pregunta Joey 02.08.2013 - 14:26
fuente

1 respuesta

6

Básicamente tienes razón. En un esquema de autenticación en el que solo hay un mensaje, de cliente a servidor, lo que sea que muestre "concede acceso" y, como tal, es equivalente a una contraseña y se puede volver a reproducir. Si el envío del hash de la contraseña funciona, entonces la contraseña de hash es equivalente a la contraseña. De hecho, lo que sugiere su colega no agrega seguridad; en cambio, agrega una sensación de seguridad, lo cual es, en igualdad de condiciones, algo malo.

resumen de HTTP es un poco mejor debido al nonce, por lo que se evita a repetición de ataques . Un concepto algo similar es contraseñas de un solo uso : esto es como el resumen HTTP, con un contador y / o el actual tiempo sirviendo como nonce (vea HOTP y TOTP .

Tenga en cuenta, sin embargo, que incluso si tiene un mecanismo de autenticación sólido que podría jugarse de forma segura a través de HTTP simple, aún sería HTTP simple. Un atacante laborioso simplemente observará la conexión, esperará a que finalice la parte de autenticación y luego secuestrará la conexión para enviar sus propias solicitudes. HTTP Digest se diseñó en un momento en el que se suponía que la mayoría de los atacantes eran pasivos, y se suponía (erróneamente) que los ataques activos eran demasiado difíciles de eliminar. La red moderna ha mostrado que esta idea no es cierta . Por lo tanto, SSL (HTTPS) es necesario de todos modos para que la parte de autenticación sea realmente "autenticar" la comunicación. Y si tiene SSL, entonces la autenticación básica (también conocida como "mostrar la contraseña") está bien.

Uno puede incluso señalar que para admitir protocolos como HTTP Digest, el servidor debe almacenar más o menos la contraseña del usuario en texto claro o con cifrado reversible, por lo que en realidad es más débil que la forma normal de almacenar contraseñas con hash .

    
respondido por el Thomas Pornin 02.08.2013 - 15:44
fuente

Lea otras preguntas en las etiquetas