Es posible recopilar un conjunto de nombres de usuario válidos interactuando con el mecanismo de autenticación de la aplicación. Esta prueba será útil para pruebas de fuerza bruta, en las que el probador verifica si, dado un nombre de usuario válido, es posible encontrar la contraseña correspondiente.
A menudo, las aplicaciones web revelan si un nombre de usuario existe en el sistema, ya sea como consecuencia de una mala configuración o como una decisión de diseño. Por ejemplo, a veces, cuando enviamos credenciales incorrectas, recibimos un mensaje que indica que el nombre de usuario está presente en el sistema o que la contraseña proporcionada es incorrecta. La información obtenida puede ser utilizada por un atacante para obtener una lista de usuarios en el sistema. Esta información puede ser utilizada para atacar la aplicación web, por ejemplo, a través de un ataque de fuerza bruta o de nombre de usuario y contraseña predeterminados.
Corrección sugerida:
El diálogo “olvidé mi correo electrónico” debe comportarse de la misma manera, ya sea que el correo electrónico sea correcto o incorrecto.
Habilitar Admin - Configuración - Inicio de sesión - ocultar dirección de correo electrónico ya registrada
ocultar dirección de correo electrónico ya registrada
No informe a los usuarios que existe una cuenta con una dirección de correo electrónico determinada durante el registro o durante el flujo de “olvidé mi contraseña”. Requerir el correo electrónico completo para las solicitudes de “contraseña olvidada”.
He estado leyendo y esto ha surgido varias veces antes. Creo que uno de los otros puntos importantes es que tenemos limitación de velocidad al intentar iniciar sesión:
Gracias a ambos. Me encontré con este error orgánicamente en meta.discourse.org y no conocía esa configuración, pero es bueno saber que la corrección ya está codificada y que el parche debería ser muy sencillo. Para cumplir con las mejores prácticas de OWASP, esa configuración siempre debe estar habilitada. No sé por qué algún administrador querría tener esto deshabilitado, ya que hacerlo representa una vulnerabilidad de seguridad y privacidad totalmente innecesaria que viola explícitamente los estándares de las mejores prácticas de la industria. Si hay alguna razón para preservar esta opción para instalaciones heredadas que no puedo comprender, entonces se debería agregar una advertencia para indicar que la configuración actual viola las mejores prácticas estándar de la industria y recomendar en su lugar la configuración compatible.
Gracias por enlazar este hilo. @awesomerobot tiene derecho a su opinión, pero también está desafiando descaradamente las mejores prácticas estándar de la industria e insistiendo en que un error conocido, frecuentemente reportado y explícitamente codificado es de alguna manera “no un error”, y no encuentro su opinión muy convincente en comparación con las mejores prácticas estándar publicadas de la industria.
Como mínimo, el valor predeterminado debería reflejar la configuración más segura, y debería haber alguna indicación para informar a los administradores novatos que deshabilitar esta opción constituye una vulnerabilidad de seguridad y privacidad deliberada e innecesaria en su foro. Un enlace a la entrada de OWASP o algo similar.
¿Alguien puede informarme sobre el escenario en el que podría ser preferible tener esta opción deshabilitada? Sinceramente, no sé por qué este es un tema controvertido y me gustaría saber si me estoy perdiendo algún caso de uso que obvie el modelo de seguridad de optar por participar que se implementa con esta configuración. Si no se puede sugerir tal escenario, entonces esta configuración siempre debería estar habilitada y, por lo tanto, no debería ser una configuración en absoluto.
Creo que, actualmente, todo funciona como se esperaba, así que no podemos clasificar esto realmente como un Bug. Sin embargo, reevaluamos rutinariamente nuestros valores predeterminados y has hecho algunos puntos interesantes que vale la pena considerar.
Deslizaré esto a UX para que la conversación pueda continuar allí.
Simplemente… la gente es mala recordando qué dirección de correo electrónico usaron para crear una cuenta y contactarán a los administradores para solucionar problemas.
Esto es similar a forzar segundo factor o longitud mínima de contraseña: creo que la recomendación general es requerir siempre un segundo factor, y las recomendaciones de longitud mínima de contraseña ahora parecen ser más altas que nuestro valor predeterminado actual para usuarios habituales… pero también hay una brecha entre las recomendaciones de seguridad y las habilidades informáticas promedio.
No estoy fuertemente en contra de cambiar los valores predeterminados, pero vale la pena señalar que pueden afectar la usabilidad.
Gracias a todos por sus valiosos aportes y perspectivas sobre este error. Para mí, esto es muy sencillo y nada complicado: existe un error bien conocido en Discourse que ha sido señalado repetidamente por administradores y profesionales de la seguridad como yo, y se está tratando como una característica en lugar de una vulnerabilidad de seguridad: NIST: CWE-200: Exposición de información sensible a un actor no autorizado.
Justificar esta configuración predeterminada insegura que viola las mejores prácticas estándar de la industria citando una situación hipotética en la que un administrador del foro se ve inundado de consultas de usuarios sobre qué correos electrónicos utilizaron para registrarse no tiene sentido, ya que el uso de la página “olvidé mi contraseña” no requeriría esta interacción del administrador, independientemente de la configuración de esta opción: si se habilita la configuración más segura y compatible con los estándares, el usuario simplemente revisará su(s) correo(s) electrónico(s) en el diálogo de “olvidé mi correo electrónico” y verá si esa dirección recibió un correo electrónico de restablecimiento de contraseña, exactamente como se explica en el diálogo, y como es común en todas las aplicaciones web modernas, respetuosas de la privacidad y compatibles con los estándares. Además, justificar esta violación basándose en la premisa de que otros sitios también podrían estar violando las mejores prácticas no es un argumento lógico ni convincente desde una perspectiva de seguridad y protección de datos. Me cuesta entender por qué estamos dando a los administradores la “característica” de hacer que su instalación de Discourse sea marginalmente menos segura y compatible con los estándares sin un beneficio claro.
Sin embargo, he realizado el trabajo que usted prescribió, @sam:
Google: no permite la enumeración de usuarios.
YouTube: no permite la enumeración de usuarios (porque utiliza el inicio de sesión de Google, y Google no permite la enumeración de usuarios).
Baidu: permite la enumeración de usuarios en la página de olvido de correo electrónico, e implementa captcha (¿y tal vez limitación de velocidad? Mi chino es malo). Curiosamente, el proceso de recuperación requiere abrir una apelación con el equipo de administración, en lugar de un simple correo electrónico de recuperación. Muy típico del control central del PCCh.
Wikipedia: no permite la enumeración de usuarios.
Yahoo: Permite la enumeración de usuarios a través de su página de olvido de contraseña, pero implementa limitación de velocidad y captcha. No pude encontrar ejemplos de Yahoo involucrado en controversias o pagando a hackers que explotan este error, pero es realmente difícil buscar Yahoo en cualquier motor de búsqueda por razones obvias.
Yandex: permite la enumeración de usuarios en la página de inicio de sesión, implementa captcha y pregunta de desafío en la página de olvido de correo electrónico.
Whatsapp: no permite la enumeración de usuarios. El inicio de sesión en PC se realiza a través de credenciales móviles. Las credenciales móviles están vinculadas a su número de teléfono. No hay botón de cierre de sesión, ni página de inicio de sesión/olvido de correo electrónico.
Xnxx: no permite la enumeración de usuarios. El sitio principal realmente no tiene una página de inicio de sesión, y el sitio ‘gold’ no permite la enumeración de usuarios. Encontré una página de inicio de sesión inactiva en la versión móvil del sitio normal, y simplemente no tiene funcionalidad de “olvidé mi correo electrónico” (y también está aparentemente inactiva, en favor de su sitio web ‘gold’).
Tik Tok: no permite la enumeración de usuarios. Aplica MFA en la página de olvido de contraseña.
(21. Reddit: No permite la enumeración de usuarios. Cumplen con las mejores prácticas estándar de la industria.)
De los 15 sitios principales de esa lista, 8/15 NO permiten la enumeración de usuarios (o 9/16 si se incluye Reddit, y se podría añadir 0.5 para Facebook ya que solo permite la enumeración de información que el usuario aprobó explícitamente hacer pública), y al menos 3/7 de los sitios de esa lista que SÍ permiten la enumeración de usuarios han enfrentado eventos de seguridad críticos como resultado de esa decisión.
Por lo demás, es trivial comprobar la existencia de cuentas en los proveedores de identidad de correo electrónico, por lo que no tiene mucho sentido incluirlos en la lista.
Ninguna de las otras plataformas de esa lista es (potencialmente) software autoalojado.
No existe una Plataforma Central de Discourse: los administradores del sitio son libres de elegir por sí mismos.
Dicho esto, estaría de acuerdo en dar un empujón a los administradores del sitio para que elijan buenas configuraciones por defecto.
Quizás un control que los administradores puedan girar (dudo en sugerir añadir esto al asistente) para ajustar fácilmente configuraciones como esta.
¿No se aplica eso a cualquier sitio con una página de registro, no solo a los proveedores de servicios de correo electrónico? Puedo ver tu punto sobre cómo las páginas de registro son un vector potencial para vulnerabilidades de privacidad y datos similares y, por lo tanto, deben protegerse, pero esa es una parte diferente del flujo de autenticación de usuario de la que estamos discutiendo en este tema. En este tema, estamos analizando específicamente las fugas del diálogo de “olvidé mi contraseña”. No me malinterpretes: ambos son absolutamente importantes, exigen una atención cuidadosa y requieren mitigaciones para prevenir vulnerabilidades de privacidad y datos. Por lo general, para los formularios de registro se requiere un captcha, y para los puntos finales de “olvidé mi contraseña” deseas tener la misma respuesta independientemente de si el correo electrónico es válido o no. Muchos sitios también aseguran el punto final de “olvidé mi contraseña” con un captcha. Ambos puntos finales deben tener límites de velocidad.
Ciertamente no intentaba ser poco sincero. De todos modos, no creo que esté bien no cumplir porque otros sitios también incumplen sea una conclusión lógicamente sólida, solo estaba cumpliendo la solicitud de Sam y para aliviar cualquier preocupación que pudiera tener al cumplir la ‘prueba’ que buscaba utilizando el enlace que proporcionó.
Ciertamente fomento la libertad del administrador y no me gusta dificultar la vida de los administradores o usuarios, pero no creo que las ‘ventajas’ de esta configuración superen las ‘desventajas’ en ningún escenario, y no hay ningún caso en el que un administrador realmente QUIERA esta ‘función’. Así como no permitimos que un administrador imponga una longitud de contraseña máxima, no deberíamos permitirles degradar innecesariamente de forma marginal la seguridad de su foro al permitir esta vulnerabilidad de enumeración en el diálogo de olvidé mi contraseña. Creo que deberíamos eliminar la opción por completo y obligar a todos a seguir la forma estándar y compatible. Honestamente, no creo que la mayoría de los administradores se den cuenta o les importe, pero haría que un punto final expuesto a la red pública fuera algo más seguro en todas las instalaciones de Discourse. Si debemos incluir la configuración, entonces debería estar en la posición más segura por defecto, y la posición menos segura debería estar claramente demarcada para que los administradores novatos entiendan por qué no se recomienda. Sin embargo, creo que simplemente refactorizar esta configuración hasta que deje de existir es la mejor opción. Estaría feliz de enviar una PR para eso.
No creo que puedas ver ninguno de los dos en el vacío. En el proceso de registro de Discourse hay un mensaje de “El correo electrónico ya ha sido tomado” y es difícil ver cómo hacerlo de manera diferente. Mientras eso exista, es difícil ver cuál es el gran problema con el mensaje “Hemos encontrado una cuenta que coincide” específicamente.
Supongo que haría una diferencia en un foro que solo permite la autenticación externa.
Habiendo superado el impulso de estar en desacuerdo contigo solo por tu estilo, creo que en el fondo tienes razón en la medida en que tu posición es que la opción predeterminada debería ser la más segura, al menos cuando se utiliza la autenticación externa. Todavía no estoy de acuerdo en que no haya lugar para la opción menos segura (mi foro tiene el proceso de registro predeterminado de Discourse, así que no planeo cambiar la opción de restablecimiento de contraseña).
Por cierto, me reí del hecho de que dejaste que el lector adivinara por el contexto que XVideos y Xnxx (aunque no X) son pornográficos, pero te tomaste la molestia de explicar que Amazon es un “sitio de comercio electrónico”.
Fue para distinguir Amazon.com de AWS. Y ya que preguntas: AWS no permite la enumeración de usuarios.
Estoy de acuerdo en que debes considerar todos los pasos de un flujo de autenticación de usuario y cómo funcionan juntos. Eso es extremadamente importante y una de las fuentes más comunes de vulnerabilidades de seguridad. Si ese error similar de enumeración de correo electrónico en la página de registro que mencionaste no se mitiga adecuadamente, entonces debe corregirse independientemente del resultado de este tema. Sería un error en la implementación de hide_email_address_taken. La discusión de ese posible error/descuido probablemente debería tener lugar en un tema diferente (y probablemente con una etiqueta de bug).
Solo para que conste, con hide email address taken habilitado, tampoco muestra ese mensaje al registrarse (también cambia el mensaje de invitación cuando se introduce un correo electrónico existente allí).
Creo que una de las posibles complicaciones para simplemente cambiar el valor predeterminado es que también incluye la opción ‘requerir correo electrónico completo para restablecer la contraseña’, lo que puede complicar demasiado las cosas (aunque probablemente no sea un bloqueo completo).
Ese es el que es. Con ocultar que la dirección de correo electrónico ya está en uso habilitado, necesitas ingresar el correo electrónico de la cuenta para restablecer la contraseña y no puedes simplemente usar un nombre de usuario.
Sugiero que cambiemos el nombre del SiteSettinghide_email_address_taken por prevent_password_recovery_by_username, y luego refactoricemos el comportamiento no conforme fuera de la aplicación para todos los usuarios. Esto preservaría la funcionalidad de restablecimiento de contraseña sin cambios para todas las instalaciones, al tiempo que abordaría la vulnerabilidad de enumeración de correo electrónico. Soy un desarrollador experto en RoR + javascript y estaría encantado de implementar esta pull request; he echado un vistazo rápido al código base y puedo ver que no sería una PR enormemente extensa.
Si la refactorización de esta “característica” para que deje de existir realmente no es una opción, entonces sigo pensando que tiene sentido desacoplar estos dos conceptos relacionados en entradas separadas de SiteSetting.
