HTTP El almacenamiento de contraseña de autenticación básica es más seguro que la autenticación de resumen

14

Si ya está utilizando SSL, parece que la autenticación básica es el camino a seguir, ya que puede realizar bcrypt con la contraseña cuando la almacena en la base de datos, donde como autenticación implícita solo permite md5 . Como sabemos, en caso de robo de la base de datos, md5 puede ser "crackeado" más rápido que bcrypt .

Mi pregunta ahora es que, dado que SSL está presente, y el hecho de que no pueda bcrypt Digest autenticación de contraseñas, ¿por qué querría usarla sobre la autenticación básica? O es la autenticación básica de la forma anterior si hay SSL.

Por cierto, esto es para un servidor de API REST

    
pregunta IMB 13.08.2012 - 17:44
fuente

4 respuestas

8

Tu suposición es correcta. La autenticación básica es el camino a seguir, siempre que esté utilizando HTTPS correctamente. Le permite implementar todas sus políticas de acceso y criptografía en la aplicación web, en lugar de estar vinculado al modelo de seguridad de su HTTPD.

    
respondido por el Polynomial 13.08.2012 - 17:46
fuente
12

La opción no es solo entre autenticación básica y autenticación de resumen si está utilizando SSL. La autenticación implícita es preferible a la autenticación básica si no tiene SSL, aunque todavía lo deja un poco vulnerable al hombre en los ataques medios; aunque las hace más complicadas que las básicas.

Sin embargo, evitaría la autenticación básica por varias razones:

  • una interfaz fea para iniciar sesión (una alerta emergente apenas configurable cuando accede por primera vez a una página protegida) frente a un formulario de inicio de sesión opcional en algún lugar de la página.
  • en un intento de inicio de sesión incorrecto, 401: los mensajes no autorizados son peores que una pantalla de contraseña incorrecta personalizable; donde tal vez agregue un CAPTCHA, o tenga enlaces que recuerden el nombre de usuario según la dirección de correo electrónico, o restablezca una contraseña perdida, o cree una nueva cuenta.
  • Por lo general, no puede cerrar sesión del inicio de sesión de Autentificación básica sin cerrar el navegador.

Por esta razón, recomiendo usar sesiones basadas en cookies (sobre SSL) por esas razones, donde nuevamente usas un hash fuerte (por ejemplo, bcrypt) para almacenar la contraseña.

    
respondido por el dr jimbob 13.08.2012 - 18:30
fuente
6

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.

    
respondido por el Thomas Pornin 27.10.2012 - 22:26
fuente
1

El almacenamiento de contraseñas para la autenticación de resumen es realmente peor de lo que sugieres. Si un atacante captura el hash de la contraseña, puede usar esto para realizar una autenticación de resumen. No se necesita agrietamiento. Como han mencionado otros, digest auth tenía su lugar antes de que SSL se extendiera.

La autenticación básica sobre SSL está básicamente bien. Sin embargo, es posible que desee considerar una solución basada en sesión. En lugar de enviar la contraseña con cada solicitud, envíela una vez para configurar una sesión, luego envíe el ID de sesión con cada solicitud. Dado que la contraseña es lo más secreto, esto minimiza la cantidad que se envía.

Otro póster mencionó el SRP, y si bien el SRP tiene varias ventajas de seguridad, no se implementa ampliamente, por lo que es un principio para la mayoría de las aplicaciones web.

    
respondido por el paj28 06.10.2013 - 16:17
fuente

Lea otras preguntas en las etiquetas