¿Por qué la autenticación basada en formularios no usa el resumen en lugar del texto simple?

  

¿Por qué la autenticación basada en formularios en los navegadores web no usa el esquema de resumen?

Un formulario HTML por sí solo no es una forma de autenticación, sino que simplemente recopila datos ingresados por el usuario y los envía al servidor. Si el servidor utiliza estos datos para la autenticación, depende del servidor. Al contrario de esto, la autenticación básica HTTP y la autenticación compacta HTTP están diseñadas específicamente para la autenticación.

Todavía es posible implementar el tipo de autenticación de Desafío-Respuesta que ofrece la autenticación mediante el uso de Javascript y hay sistemas que lo hacen. Por ejemplo, el enrutador Fritz! Box usó (y tal vez aún usa) una forma de autenticación, aunque utiliza un formulario HTML para ingresar la contraseña.

  

¿O es así que el desafío del resumen no proporcionaría ninguna seguridad adicional sobre la autenticación basada en formularios que, de todos modos, requiere TLS?

La autenticación basada en formulario no requiere TLS en absoluto. Pero es claramente recomendable hacerlo y muchos navegadores advierten hoy al enviar contraseñas utilizando HTTP simple.

El uso de la autenticación Digest a través de HTTPS no tiene ninguna ventaja en la mayoría de los casos en comparación con el uso de la autenticación Básica o los formularios HTML donde la contraseña se transmite en texto sin formato. Por el contrario, la autenticación Digest requiere que la contraseña o alguna contraseña equivalente se almacene en el servidor de forma simple, lo que aumenta el riesgo de que la contraseña o la identidad se comprometan si el servidor se ve comprometido. Consulte también Autenticación HTTP Compendio: ¿el servidor almacena las contraseñas de texto sin formato ? .

La autenticación implícita puede tener sentido si la autenticación no se realiza directamente en el servidor, sino que el propio servidor envía las credenciales a algún otro sistema de autenticación, por ejemplo, un servidor RADIUS. En este escenario, la autenticación Digest tiene la ventaja de que la aplicación web en sí nunca obtiene acceso a la contraseña simple.

  

¿es así que el desafío del resumen no proporcionaría ninguna seguridad adicional sobre la autenticación basada en formularios?

En realidad es al revés: HTTP digest auth requiere el servidor para almacenar todas las contraseñas en su base de datos en texto sin formato o con un hash débil (por ejemplo, MD5), porque debe poder calcular un resumen en ellos. Con la autenticación Básica es posible almacenar contraseñas en forma fuertemente hash (por ejemplo, scrypt), por lo que la autenticación Básica es más segura (en presencia de TLS, por supuesto).

  

¿Por qué la autenticación basada en formularios en los navegadores web no usa el esquema de resumen?

La autenticación basada en formularios no es realmente un estándar, es solo un enfoque en el que el usuario normalmente recibe un campo de formulario HTML de nombre de usuario y contraseña y un botón Enviar, que activa el envío de datos del formulario al servidor a través de un HTTP POST. Así es como funcionan normalmente los formularios HTML.

Sin embargo, puede aumentar este proceso de la forma que desee, ya que es posible interceptar los clics de los botones en JavaScript y omitir completamente el envío del formulario. Por ejemplo, puede implementar la autenticación basada en resumen a través de Ajax (por ejemplo, digest-ajax ), así como también PBKDF2 del lado del cliente , bcrypt, scrypt o realmente cualquier otra cosa.

  

¿En qué contexto sería el esquema basado en compendios realmente más seguro que el texto sin formato en un canal seguro?

Es más seguro cuando, por ejemplo, utiliza un proxy, ya que el proxy puede ver un resumen en lugar de una contraseña de texto sin formato, lo que hace posible que incluso se pueda usar un proxy público.