Sé que hay diferentes tipos de mecanismos de autenticación disponibles. Uno de ellos es la autenticación HTTP. ¿Cuál es el peligro de usar este método en comparación con otros métodos?
Sé que hay diferentes tipos de mecanismos de autenticación disponibles. Uno de ellos es la autenticación HTTP. ¿Cuál es el peligro de usar este método en comparación con otros métodos?
La autenticación básica tiene varios inconvenientes, uno de los cuales es que el nombre de usuario y la contraseña se pasan de forma clara con cada solicitud. Esto es claramente inseguro bajo HTTP, pero es algo menos vulnerable bajo HTTPS. Sin embargo, dado que las credenciales se envían con cada solicitud, aún es peor que cualquier otro método (incluido el resumen) que no tenga esta limitación. La razón principal es que ahora cada solicitud individual puede ser un objetivo para el robo de credenciales de texto simple, no solo una solicitud de inicio de sesión inicial. En la mayoría de los sistemas, después de iniciar sesión, lo máximo que un atacante puede esperar recuperar es una sesión o un token de autenticación. Con la autenticación básica, cualquier solicitud es una oportunidad para robar la contraseña del usuario. Esto no es lo ideal.
La autenticación del compendio es algo mejor, ya que envía un resumen MD5 de varios bits, incluido el nombre de usuario, la contraseña y un nonce (entre otros valores) y no las credenciales de texto claro ... No se puede extraer una contraseña de un resumen capturado .
Con la autenticación HTTP (en cualquier forma), también depende del cliente para proporcionarle la experiencia de usuario de autenticación, que puede tener sus propios problemas y, por lo tanto, debe ser bien probada con los clientes que espera usar con su aplicación. En el pasado, por ejemplo, he visto navegadores específicos que no se autentican debido a ciertos caracteres especiales en una contraseña, por ejemplo. Con la autenticación basada en aplicaciones UX, usted tiene control sobre esto. Con la autenticación HTTP, no lo hace.
Otro ataque (y es uno muy menor) es que si muestra en su sitio contenido generado externamente y alojado en su sitio, se abre a ataques de phishing 401 muy sutiles. Dado que sus usuarios están acostumbrados al chrome del cliente para la autenticación HTTP, no necesariamente se darán cuenta si reciben una solicitud de autenticación en su sitio para un dominio ligeramente diferente. Dependiendo de su aplicación, esto puede no ser una amenaza válida en absoluto, pero ciertamente es algo a tener en cuenta si se baja por la ruta de autenticación HTTP.
Además de los otros puntos mencionados, otro inconveniente importante de la autenticación básica HTTP (en comparación con, por ejemplo, el inicio de sesión basado en formularios) es que no tiene el concepto de "cierre de sesión". Una vez que el usuario ingresa sus credenciales, el navegador las almacena internamente para enviarlas con cada solicitud posterior. Esto significa que no puede tener un tiempo de espera o un botón / enlace "Cerrar sesión" para finalizar la sesión. Si el usuario desea evitar la posibilidad de que otra persona utilice su sesión (por ejemplo, en el caso de una computadora compartida), debe acordarse de abandonar el navegador.
Para obtener más información: enlace
La autenticación de acceso básica a través de HTTPS tiene claras ventajas sobre la autenticación de acceso mediante Digest a través de HTTP.
Incluso con la autenticación de acceso de resumen, puede almacenar sus contraseñas con un salt único (realm + username), pero primero se puede adivinar este salt (esto hace que los ataques contra usuarios individuales y grupos pequeños sean más fáciles), y segundo, puede ' t use bcrypt , scrypt o PBKDF2 para hacer que el cálculo de hash sea más difícil. Además, si eligió almacenar los hashes en un formato no recuperable (¡debería hacerlo!), No puede cambiar el dominio sin requerir la contraseña de usuario clara.
En SASL , digiere la autenticación de acceso incluso ha sido marcado como histórico por IETF. Para SASL, tenían una alternativa ( SCRAM , que claramente exige SASLPrep para la normalización de caracteres, por ejemplo) que podrían recomendar usar en su lugar. SCRAM para HTTP desafortunadamente nunca aprobó el estado de borrador (Tenga en cuenta que con SCRAM, Las sales tampoco son secretas. El atacante puede abusar del mecanismo de inicio de sesión para obtener sales para cada usuario que desee).
La autenticación de acceso implícita puede dar una falsa sensación de seguridad . Si el atacante puede capturar un inicio de sesión exitoso, puede montar un ataque de fuerza bruta contra la contraseña. username , realm y nonce son valores conocidos para el atacante.
El uso de HTTP sin cifrar es, con o sin autenticación de acceso mediante Digest, no es inmune a MITM. Es posible que el atacante no pueda capturar la contraseña, pero puede capturar cookies de sesión, modificar el contenido o hacerse pasar por el usuario.
La autenticación de acceso de resumen solo se especifica para el inicio de sesión, pero no para la configuración de la cuenta. Tienes que hacer la configuración de la cuenta de la "manera habitual". Incluso si su código es inteligente y solo envía el hash interno para evitar que la contraseña se transporte en texto sin cifrar, el atacante puede modificarla para que también se la transmita. Sin embargo, este problema grave existe solo una vez, en el registro . Suponiendo que el usuario inicie sesión desde solo una pequeña cantidad de máquinas, puede lograr una seguridad similar utilizando TACK para HTTPS. Esto permite que el navegador del usuario solo autorice el certificado que obtuvo en la primera conexión al sitio. Así que solo la primera conexión queda expuesta a un MITM posible, al igual que con la autenticación de acceso de resumen.
Lea otras preguntas en las etiquetas web-application authentication http