| Artículos | 01 JUL 2010

Seguridad en la autenticación web

Tags: Histórico
Guía de buenas prácticas para autenticar a los usuarios web de forma segura usando nombre y contraseña
Gonzalo Álvarez.
Uno de los puntos más vulnerables en una aplicación web es su sistema de autenticación basado en nombre de usuario y contraseña. Mal diseñado, el mecanismo de autenticación puede ser fuente de intrusiones: contraseñas débiles, fuerza bruta, mensajes de error excesivamente verbosos, transmisión vulnerable de credenciales, cambio de contraseñas deficiente, recuperación pobre de contraseñas olvidadas, nombres de usuario o contraseñas predecibles, o almacenamiento inseguro de contraseñas, por señalar algunos ejemplos. En este artículo se repasan las peores vulnerabilidades en la lógica de autenticación basada en contraseñas y cómo mitigarlas.

Irónicamente, aunque la autenticación basada en nombre de usuario y contraseña es la forma más débil de autenticación, se trata sin embargo de la más utilizada en todo tipo de aplicaciones web. Una fuente común de intrusiones radica en vulnerabilidades en su lógica de autenticación. A pesar de su aparente simplicidad, diseñar un sistema seguro basado en contraseñas presenta complejos desafíos. Aunque algunas de sus debilidades intrínsecas cuentan con difícil solución, otras pueden superarse mediante la implantación de unas sencillas prácticas de seguridad. En este artículo se analizan en detalle las vulnerabilidades más frecuentes y cuáles son las mejores contramedidas para eliminarlas o cuando menos mitigarlas.

Tecnologías de autenticación en entornos web
A la hora de diseñar un sistema de autenticación, al desarrollador web se le presentan una serie de opciones básicas: autenticación basada en formularios, autenticación HTTP BASIC, autenticación HTTP DIGEST, autenticación basada en certificados SSL de cliente, autenticación de Windows integrada mediante NTML o Kerberos. Exceptuando la basada en certificados, todas las demás requieren credenciales compuestas por un nombre de usuario y una contraseña.
Indiscutiblemente, la más utilizada es la autenticación basada en formularios por sus numerosas ventajas: utiliza un formulario HTML para solicitar las credenciales, lo que permite una interfaz de usuario totalmente personalizable; proporciona flexibilidad absoluta en el almacenamiento de credenciales, pudiéndose conservar éstas en cualquier lugar: base de datos, archivo XML o archivo de texto, por ejemplo; resulta ideal para escenarios en Internet, ya que funciona con cualquier navegador y con cualquier tipo de servidor. Dada su gran flexibilidad, en aplicaciones web que requieren mayor seguridad, como las bancarias, el nombre de usuario y contraseña puede complementarse con otra información sólo conocida por el usuario, como un PIN secreto o números impresos en una tarjeta de coordenadas. En cualquier caso, esta información sigue enviándose a través de un formulario.
Esta gran flexibilidad es también su peor enemigo, ya que los desarrolladores se encuentran con innumerables opciones a la hora de diseñar el sistema de autenticación, a menudo partiendo desde cero. Por fortuna, este abandono en que se encontraban ha sido superado con los nuevos frameworks de desarrollo, como .NET 3.5. A continuación se repasan cuáles son las vulnerabilidades y errores de diseño comúnmente encontrados en la lógica de autenticación de aplicaciones web.

Contraseñas débiles
Los usuarios son perezosos y su memoria, frágil. Como resultado, tienden a elegir contraseñas débiles: conservan la predeterminada, usan una igual al nombre de usuario, o de poca longitud o formada por palabras fáciles de recordar… y de adivinar. No puede confiarse en que los usuarios elegirán contraseñas robustas por mucho que se les haya concienciado y educado.
Soluciones:
Obligue a sus usuarios a usar contraseñas robustas. Implante unas directivas de contraseñas que contemplen alguno o todos de los siguientes aspectos: 1) complejidad de contraseñas: si la contraseña es fácil de adivinar o muy corta, caerá rápidamente ante ataques de diccionario o de fuerza bruta (tratados más adelante), por lo que debe establecerse siempre una longitud mínima de por ejemplo 12 caracteres, obligar a mezclar caracteres alfanuméricos y signos de puntuación o mayúsculas y minúsculas, por ejemplo; 2) bloqueo de cuentas: para evitar que un atacante pruebe indefinidamente distintas contraseñas hasta dar con la correcta, puede considerarse el configurar un umbral de intentos de inicio de sesión fallidos, traspasado el cual, la cuenta atacada se bloquea durante un tiempo también configurable o hasta que el usuario la desbloquee por otro canal; 3) caducidad de contraseñas: si las contraseñas pueden durar eternamente, se abre una ventana de tiempo ilimitada durante la que se pueden hacer pruebas o durante la cual el usuario puede terminar revelándola, voluntaria o involuntariamente, por lo que debe obligarse a que las contraseñas expiren al cabo de un período de tiempo determinado, transcurrido el cual no queda más remedio que cambiarlas; 4) historial de contraseñas: si la nueva contraseña se elige igual a la anterior u otra usada recientemente, poco se habrá adelantado, por lo que debe prohibirse la reutilización de contraseñas antiguas, para lo que hace falta claro está conservar un histórico de las mismas.

Mensajes de error excesivamente verbosos
Los formularios de petición de credenciales típicos solicitan dos datos del usuario: un identificador, que puede ser un nombre de usuario, un número de tarjeta de crédito o su DNI, entre otros; y una contraseña o un PIN asociados a ese identificador. Una o ambas de estas dos informaciones pueden ser incorrectas, lo que producirá un error de autenticación. El servidor puede reaccionar de varias maneras: 1) puede mostrar un mensaje de error genérico que simplemente informe al usuario de que “las credenciales son incorrectas” o “no se ha podido validar la identidad del usuario”, con independencia de qué dato era incorrecto; 2) si el usuario introdujo incorrectamente el identificador, puede mostrar un mensaje informando de que “el nombre de usuario es incorrecto”; mientras que 3) si el usuario falló al introducir la contraseña, el servidor puede informarle de que “la contraseña es incorrecta”. Esta diferencia en los mensajes de error, aparentemente tan inocente, permite a un atacante enumerar los identificadores válidos por el sencillo método de prueba y error. El conocimiento de la lista completa de usuarios de la aplicación puede utilizarse muy provechosamente en futuras fases del ataque.

Soluciones:
Utilice el mismo mensaje de error genérico con independencia de la causa del error. No procese de forma diferente ambos tipos de error, no sólo en cuanto a mensajes al usuario, sino también en cuanto a códigos de estado, redirecciones, tiempos de servicio o código HTML, entre otras posibilidades.

Posibilidad de ataques de fuerza bruta
Por definición, las contraseñas son vulnerables a ataques de fuerza bruta, consistentes en pro bar todas las posibles combinaciones de caracteres para una longitud determinada. Puesto que la mayoría de usuarios no utiliza contraseñas aleatorias sino basadas en nombres de personas, cosas o lugares, estos ataques suelen agilizarse utilizando diccionarios de palabras comunes. De hecho, la mayoría de usuarios utiliza contraseñas muy f

Contenidos recomendados...

Comentar
Para comentar, es necesario iniciar sesión
Se muestran 0 comentarios
X

Uso de cookies

Esta web utiliza cookies técnicas, de personalización y análisis, propias y de terceros, para facilitarle la navegación de forma anónima y analizar estadísticas del uso de la web. Consideramos que si continúa navegando, acepta su uso. Obtener más información