Mensaje de error genérico para una contraseña o nombre de usuario incorrectos: ¿es esto realmente útil?

No, tiene razón en que, en algún momento durante los esfuerzos para evitar que los atacantes determinen las identidades de usuario válidas, tendrá que mentirles o proporcionarles mensajes de error excepcionalmente vagos.

Su aplicación podría decirle a un usuario que "el nombre de usuario solicitado no está disponible" y no ser específico en cuanto a si ya estaba en uso o simplemente no cumplía con sus otros requisitos de nombre de usuario (longitud, uso de caracteres, palabras reservadas, etc. ). Por supuesto, si estos detalles son públicos, entonces un atacante podría descubrir que su suposición falló debido a que la cuenta estaba en uso y no a un formato no válido.

Entonces usted también tiene su sistema de restablecimiento de contraseña. ¿Acepta algún nombre de usuario / dirección de correo electrónico y dice que se envió un mensaje incluso si esa cuenta no estaba en su base de datos? ¿Qué pasa con el bloqueo de cuenta (si lo estás usando)? ¿Le acaba de decir al usuario que sus credenciales no eran válidas incluso si no lo fueran, sino que su cuenta fue bloqueada, esperando que se pongan en contacto con el servicio de atención al cliente que puede identificar el problema?

Es beneficioso aumentar la dificultad para que los atacantes recopilen nombres de usuario válidos, pero generalmente es un costo para los usuarios frustrados. La mayoría de los sitios de menor seguridad que he visto utilizan mensajes separados que identifican si el nombre de usuario o la contraseña son incorrectos simplemente porque prefieren errar por el lado de mantener a los usuarios felices. Tendrá que determinar si sus requisitos de seguridad dictan prioridad sobre la experiencia del usuario.

Está asumiendo que el sistema realmente sabe qué campo se ingresó incorrectamente. Hay varias razones por las que esto no es necesariamente cierto.

Una posibilidad es que es un efecto secundario de la implementación. Un método simplista para buscar inicios de sesión en una base de datos podría parecerse a algo (usando :n para los parámetros proporcionados por el usuario):

SELECT 1
  FROM users
 WHERE username=:1 AND
       password=HASHING_FUNCTION(CONCAT(:2, salt))

Si obtiene un resultado vacío, sabe que el inicio de sesión debe fallar, pero no sabe por qué, a menos que haga algo más complicado o realice otra consulta. Así que a veces puede ser simplemente la pereza o el deseo de ir fácil en la base de datos, en lugar de una decisión de seguridad consciente.

Pero incluso si la implementación puede distinguir entre un usuario inexistente y credenciales incorrectas, todavía tiene la situación en la que un usuario ingresa su contraseña correctamente, pero el nombre de usuario es incorrecto, y ese es un usuario que existe (con una contraseña diferente ). Luego, si el usuario recibe un mensaje que dice que su contraseña es incorrecta, sería incorrecto. Entonces, a menos que el nombre de usuario especificado no exista, el sistema no puede saber realmente si fue el nombre de usuario o la contraseña incorrectos.

En general, es más difícil aplicar una página de registro a una fuerza bruta que a una página de inicio de sesión, por lo que nos beneficiamos de este costo adicional. Pero, en concepto, tienes razón. Hay otras formas de enumerar nombres de usuario que iniciar sesión en los mensajes de la página.

Es simplemente 'Good Practice' (TM) mantener un registro de mensajes genéricos de fallas para dificultar que los atacantes obtengan buenas cuentas. Usando una herramienta de fuerza bruta, es trivial probar nombres aleatorios, y luego, cuando cambia el mensaje de error, comenzar a forzar ese nombre de usuario.

Pero, como siempre, debe equilibrar la facilidad de uso con la reducción de amenazas.

No todos los sistemas tienen registro de cuenta. Por ejemplo, el inicio de sesión de su sistema operativo no lo hace. Los sitios web dejan de aceptar nuevos miembros de vez en cuando.

Es una cuestión de separación de inquietudes: ¿debería el diálogo de inicio de sesión consultar la configuración del sistema y personalizar su comportamiento en función de si el sistema está configurado para aceptar solicitudes de nuevas cuentas o no? Luego, el cuadro de diálogo de inicio de sesión está acoplado a información que no es realmente relevante para su trabajo.

Parece más fácil implementar el vago mensaje de error en todos los casos (suponiendo que el software de la interfaz de usuario incluso sepa si la contraseña es incorrecta o la cuenta no existe: qué sucede si obtiene un error de autenticación genérico de algún nivel inferior API?)

Y, también: la nueva interfaz de usuario de la aplicación de usuario puede implementar un retraso falso de larga duración como "buscar en la base de usuarios ... [10 segundos] ... ¡Vaya, el nombre de usuario ya está en uso!" Si se implementa, significa que el sondeo del espacio de ID de usuario a través de este mecanismo está muy limitado por la velocidad. Dado que solicitar una nueva cuenta es una operación rara, que se realiza una sola vez, los usuarios sufrirán la demora, mientras que se verán agravados por una demora de diez segundos en el diálogo de inicio de sesión regular.

Depende de cuál sea el nombre de usuario. Hay tres enfoques principales para los nombres de usuario:

• Nombre seleccionado por el usuario
• dirección de correo electrónico
• Nombre de usuario asignado: generalmente una cadena de dígitos

Tiene razón en que, para los nombres seleccionados por el usuario, un atacante puede usar el proceso de registro para deducir qué nombres están en uso, por lo que hay un beneficio limitado para el inicio de sesión que devuelve un mensaje genérico.

Sin embargo, para los otros dos casos, es mucho más importante que la pantalla de inicio de sesión devuelva un mensaje de error genérico. Considere un sitio de reclutamiento, podría ser embarazoso para [email protected] que su jefe descubra que hay una cuenta en un sitio de reclutamiento. Y los nombres de usuario asignados se usan más comúnmente en sitios de alta seguridad como la banca en línea.

Sí, tienes razón. En cualquier lugar de su sitio donde pueda confirmarse que existe un nombre de usuario o no, puede llevar a username enumeration .

Sin embargo, este problema se puede resolver si es importante para su sistema. En algunos sistemas, la enumeración del nombre de usuario no se puede evitar ya que es inherente a la naturaleza de la aplicación. Un ejemplo es un servicio de correo web: aquí las direcciones de correo electrónico se consideran potencialmente públicas. Impedir que los usuarios conozcan otros nombres de usuario es difícil sin requerir que los usuarios inicien sesión con un identificador diferente al de su dirección de correo electrónico alojada y pueden generar confusión y dificultad para recuperar las credenciales perdidas.

Sin embargo, con la mayoría de los otros sistemas, esto puede solucionarse teniendo la dirección de correo electrónico del usuario como su nombre de usuario de inicio de sesión. Resolvería el problema teniendo la contraseña olvidada y el formulario de registro como efectivamente la misma página. Para registrarse, este sería un formulario de varios pasos y el primer paso simplemente solicita el nombre de usuario (correo electrónico) que el usuario desea usar con su sistema. Para la recuperación de la cuenta, esta sería la misma forma pero el título diría algo similar a Please enter your email address to generate a password recovery email .

En ambos casos, el formulario enviará al usuario un correo electrónico. Si ya están registrados, el contenido de este correo electrónico contiene un enlace para restablecer la contraseña. Si no están registrados, el contenido de este correo electrónico contiene un enlace a la siguiente etapa del proceso de registro. Esto evitará que los nombres de usuario en su sistema sean enumerados, por lo que un atacante no sabrá a qué cuentas dirigirse.

Por supuesto, esto implica que está dispuesto a permitir que las contraseñas se restauren por correo electrónico, lo que puede ser inaceptable para algunas aplicaciones, como las aplicaciones bancarias. Sin embargo, como este tipo de cuentas generalmente tienen controles de seguridad adicionales, generalmente tienen nombres de usuario asignados por el banco en lugar de permitir que las personas elijan sus propios.

El argumento común para mensajes vagos parece ser evitar que los atacantes adivinen nombres de usuarios válidos. En realidad, hay una solución simple que no afecta gravemente a los usuarios legítimos y debería estar implementada de todos modos: restringir el número máximo de intentos fallidos en un período de tiempo.

Al restringir los intentos, previene todos los ataques de fuerza bruta. Digamos que solo se permiten 5 intentos por 15 minutos (común en los foros), lo que hace que un ataque de adivinación de nombre de usuario sea inútil. También evita el forzamiento de la contraseña (de todos modos, tan inútilmente lento como lo sería en un sitio remoto).

Por supuesto, es posible que un atacante ya tenga una base de datos de nombres de usuarios y simplemente desee verificar si existen en su sitio. Y tendrá que considerar las implicaciones de seguridad de eso, pero generalmente ya tienen la contraseña (lo que hace que este debate sea discutible) o no lo harán (por lo que los intentos restringidos impiden la adivinación).

Un sitio web inteligente tendría un captcha en su página de registro para evitar este tipo de cosas.

Pero ya sabes cómo es el 99% de los sitios web. Arruinarán su UX con un mensaje de error genérico, aunque no les dé ninguna seguridad adicional. Personalmente, no me molesto con los mensajes de error genéricos, ya que existen muchas otras restricciones para mis inicios de sesión (captchas, intentos de inicio de sesión limitados), además de que los inicios de sesión son como la razón número 1 por la que las personas abandonan un sitio web.

Si eliges mostrar un mensaje de error genérico, entonces, Dios mío, sigue adelante. Asegúrese de que no haya cabos sueltos en ninguna parte. Puedes reforzar una pared con acero de 10 pulgadas de espesor, pero eso no ayudará si hay una puerta abierta.

Estoy tratando de ponerme el sombrero de atacante y veo 2 casos:

1. Su sitio tiene una página de registro (como gmail o stackoverflow). Podría usar la página de registro para averiguar el nombre de usuario de un usuario existente por fuerza bruta. O simplemente podría crear un nuevo usuario. Mi nuevo usuario de gmail o stackoverflow probablemente tendrá aproximadamente los mismos derechos que el que tendría forzado en bruto.

2. Su sitio no tiene una página de registro. Tu punto es nulo.