La Especificación del protocolo de resumen data de 1999, que fue una época en la que SSL todavía se veía como una herramienta demasiado cara para Ser empleado genéricamente. El RFC comienza con este párrafo, que da el contexto:
"HTTP / 1.0", incluye la especificación para un acceso básico
Esquema de autenticación. Este esquema no se considera un seguro
método de autenticación del usuario (a menos que se utilice junto con algunos
sistema seguro externo como SSL 5 ), como el nombre de usuario y
Las contraseñas se pasan a través de la red como texto simple.
Esta es la única referencia a SSL en todo el documento. Esto aclara las cosas: Digest se diseñó para tratar de resolver el problema evidente de enviar contraseñas de forma clara, como hace Basic cuando no se usa con SSL . Sin embargo, sabemos que no usar SSL es un gran problema, ya que los atacantes han avanzado un poco desde el siglo pasado: ya no se contentan con la escucha pasiva, en realidad secuestran conexiones e implementan ataques de man-in-the-middle . Ninguna cantidad de Digest te salvará en ese caso.
Tenga en cuenta que una posible ventaja de Digest sobre Basic es que no revela la contraseña ni siquiera al servidor mismo, en caso de que el servidor sea hostil, por lo que quiero decir que está hablando con un servidor falso, controlado por el agresor. El compendio no protegerá contra un MitM, por lo que en esa situación ya está condenado, pero solo localmente condenado: el atacante puede ver sus datos y modificar sus solicitudes, pero no aprende su contraseña, por lo que No podrá volver más tarde solo. Varios puntos hacen que esta ventaja sea muy pequeña:
-
A pesar de que el Digest con un servidor falso no revela la contraseña sin procesar al atacante, todavía proporciona suficiente para ejecutar un ataque de diccionario , y muy eficiente, ya que es solo un par de hashes MD5 (nada remotamente comparable a bcrypt).
-
El ataque MitM inherente es lo suficientemente serio como para exigir las verificaciones correctas de integridad de los datos, lo que significa SSL (con la validación completa del certificado del servidor, ¡por favor!). Si MitM es derrotado, entonces la ventaja de Digest sobre Basic se evapora como rocío en el sol de la mañana.
Por otra parte, como ha señalado, el uso de Digest implica que el servidor debe almacenar las contraseñas (posiblemente encriptadas, pero de manera reversible), y que es un gran inconveniente de Digest autenticación.
Para el mejor de todos los mundos, use TLS con SRP que es SSL / TLS con una contraseña muy buena. intercambio de claves basado, donde:
- el servidor no necesita almacenar la contraseña, solo un token de verificación (un tipo de hash);
- no hay ningún certificado en absoluto;
- la autenticación es mutua y relativa a la contraseña;
- incluso un atacante que se hace pasar por el servidor, el cliente o ambos, no puede obtener datos suficientes para ejecutar un ataque de diccionario sin conexión.
El único problema "menor" es que TLS + SRP no es ampliamente compatible (todavía). GnuTLS puede hacerlo. Podemos esperar un mayor apoyo en el futuro. Mientras tanto, use la autenticación básica dentro de SSL, no olvide validar a fondo el certificado del servidor y use bcrypt para almacenar un hash de contraseña del lado del servidor.