“Nombre de usuario y / o contraseña no válidos”: ¿Por qué los sitios web muestran este tipo de mensaje en lugar de informar al usuario cuál de los dos estaba equivocado?

Si un usuario malintencionado comienza a atacar un sitio web adivinando combinaciones comunes de nombre de usuario / contraseña como admin / admin, el atacante sabría que el nombre de usuario es válido si devuelve un mensaje de "Contraseña no válida" en lugar de "Nombre de usuario o contraseña no válida" .

Si un atacante sabe que el nombre de usuario es válido, podría concentrar sus esfuerzos en esa cuenta en particular mediante el uso de técnicas como inyecciones de SQL o el uso de la contraseña.     

Como han mencionado otros, no queremos que sepa si el nombre de usuario o la contraseña fueron incorrectos o no, por lo que no somos tan susceptibles a brute-force o ataques .

Si algunos sitios web quisieran que sus usuarios se dieran cuenta de cuál de ellos falló mientras aún estaban en la seguridad ecológica, podrían implementar " honeypot " nombres de usuario (como Administrador, administrador, etc.) que alertarían a los administradores del sitio web de que alguien está husmeando en su sitio. Incluso podría configurar alguna lógica para prohibir su dirección IP si intentaran iniciar sesión con uno de esos nombres de usuario "honeypot". Conozco a una persona que realmente tenía un sitio web y puso en su código fuente un comentario HTML como "Ya que siempre olvida a Richard: Nombre de usuario: queso Contraseña: Burger123" cerca del cuadro de inicio de sesión con la intención de monitorear cualquier dirección IP que haya intentado usar. ese nombre de usuario / contraseña. Agregar una lógica de monitoreo como esta es muy divertido cuando estás desarrollando un sitio web.

Por supuesto, el registro de intentos de inicio de sesión no válidos y la adición de la lógica adecuada para tratar con esas direcciones IP también funciona. Sé que algunos no estarían de acuerdo conmigo, pero según el tipo de sitio web, no creo que sea una gran oferta informar al usuario siempre que agregue medidas de seguridad adicionales para prevenir diferentes tipos de ataques.

Mi implementación segura favorita de esto la realiza un banco que uso. Si escribo mi nombre de usuario correctamente, dirá "¡Bienvenido Jimbob!" y luego me pide que responda las preguntas de seguridad (si nunca he iniciado sesión desde este navegador en esta computadora), espere a que responda las preguntas de seguridad correctamente y luego me permita ver mi imagen / título de seguridad e ingresar mi contraseña. Si escribo el nombre de usuario incorrecto, veré algo como "¡Bienvenido Bessie / Kareem / Randal!" donde el nombre que se muestra es muy poco común, aunque siempre tendrá el mismo nombre para un mismo nombre de usuario (por lo general no estoy seguro entre uno o dos nombres de usuario y el nombre equivocado me llama Frenshelia). Supongo que se implementa como una especie de hash no criptográfico aplicado a cualquier nombre de usuario ingresado que se asigna de forma única a un nombre de usuario en una larga lista de nombres bastante poco comunes. Esto permite a los usuarios legítimos saber si escribieron el nombre de usuario incorrecto (ya que incluso si tienes un nombre poco común como Bessie; es muy poco probable que el nombre de usuario incorrecto que adivinaste de forma aleatoria se asigne a tu nombre no específico), sin que sea obvio para las personas que intentan para encontrar cuentas al azar que el nombre de usuario no existe.

Como nota aparte: no me gustan especialmente las preguntas de seguridad / parte de la imagen de seguridad, que parece estar en el teatro de seguridad. Un atacante sofisticado que realiza un ataque Man-in-the-middle (MITM) (por ejemplo, después de instalar certificados falsos en su navegador web y la falsificación de DNS / ARP para apuntar yourbank.com a su dirección IP) podría esperar hasta que intente el registro en el sitio, luego haga que un script automatizado inicie sesión en su computadora al sitio real, obtenga las preguntas de seguridad, muestre las preguntas de seguridad elegidas, envíe las respuestas al sitio desde su navegador, espere para obtener la seguridad imagen, devuelva la imagen de seguridad a usted y luego espere a que ingrese la contraseña desde su extremo, momento en el que la usa para iniciar sesión como usted y hacer cosas maliciosas. Concedido, las preguntas y la imagen hacen que el proceso sea más difícil que tener todo el tiempo del mundo para recopilar todas las imágenes de seguridad para una variedad de nombres de usuario atacados al convertirlo en un ataque que debe realizarse en tiempo real y posiblemente deje una firma sospechosa. .

Otras respuestas proporcionan una buena visión de las razones de seguridad detrás de este comportamiento. Aunque son correctos, estoy bastante seguro de que al menos algunos simplemente tienen la rutina de autorización programada de la forma en que es imposible decir qué fue lo que estaba mal: inicio de sesión o contraseña.

Consulta de muestra:

SELECT COUNT(*) FROM users WHERE login = 'john' AND hash = '2bbfcdf3f09ae8d700402f36913515cd'

Esto devolverá 1 en un intento de registro exitoso y 0 si no hay un usuario con dicho nombre o este usuario tiene una contraseña diferente. No hay manera de saber qué parte de la condición falló. Entonces, cuando se trata de mostrar un mensaje de error, el programador simplemente le dice honestamente que algo está mal y que no está realmente seguro de qué es exactamente.

Personalmente vi consultas similares en algunos sitios web basados en PHP, así que estoy bastante seguro de que parte de la razón se debe a la manera en que se codifica el proceso de autenticación.

Sin embargo, existe otra técnica interesante que se puede aplicar para realizar un user enumeration attack (y más). Se llama Timing attack . El atacante simplemente mide el tiempo de respuesta de la solicitud de autenticación y cómo difiere entre un inicio de sesión válido y otro no válido.

1. Ataques de tiempo remotos a escala de nanosegundos en aplicaciones PHP: ¿Es hora de tomarlos en serio?
   enlace

2. Una lección sobre los ataques de tiempo
   enlace

3. Comparación de cadenas de tiempo constante en PHP para evitar ataques de tiempo
   enlace

Lo importante es que ese mensaje no es suficiente si desea proteger su aplicación contra este tipo de amenaza.

La razón de seguridad es que, de lo contrario, es mucho más fácil encontrar nombres de usuario válidos.

Además de todas las grandes respuestas que ya se dieron, hay un principio de seguridad genérico que dice que no debe proporcionar información no solicitada a usuarios no autorizados. Es decir. Si tiene la opción de responder "sus datos de autenticación no son válidos" o explicar qué parte no es válida, siempre debe elegir la primera. Algunos ataques criptográficos muy desagradables se basan en la cantidad más pequeña de información de errores proporcionada por la implementación que intenta ser "útil"; consulte ataque oracle padding . Por lo tanto, es una buena idea optar siempre por la información más pequeña posible revelada a la entidad no autorizada, es decir, si su combinación de nombre de usuario / contraseña no es buena, siempre responda "nombre de usuario / contraseña no es buena", y nunca más divulgue datos. Incluso si en un caso específico (como gmail donde el nombre de usuario es público) no es importante, es una buena práctica adoptar por defecto.

Supongamos que ingresa un nombre de usuario aleatorio y una contraseña igualmente aleatoria (solo tenga en cuenta qué contraseña ingresó). Ahora las contraseñas pueden ser comunes entre los n usuarios. Entonces, si el sitio web dice que la contraseña es correcta ... entonces sabrá lo que sigue a continuación ... caos entre los usuarios genuinos, ya que obtener nombres de inicio de sesión es bastante fácil.

Brindar una respuesta ambigua es útil para prevenir el enumeración de usuarios .

En algunos casos, el atacante no necesita comprometer la cuenta de usuario. La información que el usuario tiene cuenta es suficiente sin ninguna otra acción. Por ejemplo, es una información valiosa para el comercio que sus clientes tienen en cuenta en una tienda web competitiva.

Aprecio las diversas respuestas anteriores, ya que son las que más dicen, pero a veces las aplicaciones tampoco saben qué es un Nombre de usuario o Contraseña incorrectos. En el caso de una autenticación basada en token especialmente para implementar SSO (Single Sign On), por ejemplo. IBM Tivoli Access Manager su aplicación recibe un token exitoso o recibe un error.

si el inicio de sesión es una dirección de correo electrónico, es fácil descubrir que una persona está registrada en un sitio web; es posible que no quiera que > > A veces, las personas usan la contraseña real de la cuenta de correo electrónico para los sitios web que registran cuando usan la identificación del correo electrónico como identificación de inicio de sesión :)