La guía paso a paso o código que encontrarás en este artículo es la solución más rápida y efectiva que hallamos a tu duda o dilema.
Solución:
No, tiene razón en que, en algún momento durante los esfuerzos para evitar que los atacantes determinen 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 especificar 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, un atacante podría darse cuenta de que su suposición falló debido a que la cuenta está en uso y no a un formato no válido.
Entonces también tienes tu sistema de restablecimiento de contraseña. ¿Acepta cualquier 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á usando)? ¿Simplemente le dice al usuario que sus credenciales no eran válidas, incluso si no lo fueran, sino que su cuenta fue bloqueada, con la esperanza de que se comunique 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 normalmente tiene el costo de frustrar a los usuarios. La mayoría de los sitios de menor seguridad que he visto usan mensajes separados que identifican si el nombre de usuario o la contraseña son incorrectos solo porque prefieren errar para mantener contentos a los usuarios. Tendrá que determinar si sus requisitos de seguridad dictan priorizarlos sobre la experiencia del usuario.
Está suponiendo que el sistema realmente sabe qué campo se ingresó incorrectamente. Hay varias razones por las que esto no es necesariamente true.
Una posibilidad es que sea un efecto secundario de la implementación. Un método simplista de buscar inicios de sesión en una base de datos podría parecerse a (utilizando :n para 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 debería fallar, pero no sabe por qué, a menos que haga algo más complicado o realice otra consulta. Entonces, a veces puede ser solo pereza o un deseo de ser fácil con 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, aún existe la situación en la que un usuario ingresa su contraseña correctamente, pero el nombre de usuario incorrecto, y ese es un usuario que existe (con una contraseña diferente). Entonces, si el usuario recibe un mensaje que dice que su contraseña es incorrecta, eso sería incorrecto. Entonces, a menos que el nombre de usuario especificado no exista, el sistema hipocresía realmente saber si era el nombre de usuario o la contraseña lo que estaba mal.
En general, es más difícil aplicar fuerza bruta a una página de registro que aplicar fuerza bruta 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 los nombres de usuario además de los mensajes de la página de inicio de sesión.
Es simplemente una ‘buena práctica'(TM) mantener los mensajes de error de inicio de sesión genéricos para que sea más difícil para los atacantes distinguir las cuentas buenas de las malas. 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 usabilidad con la reducción de amenazas.