¿Hay alguna razón para no mostrar a los usuarios las contraseñas ingresadas incorrectamente después de un inicio de sesión exitoso?

219

Nuestro cliente tiene el requisito de que, en caso de que el nombre de usuario en cuestión haya tenido varios intentos fallidos de inicio de sesión, las contraseñas ingresadas incorrectamente deben mostrarse una vez que se realiza un inicio de sesión exitoso. La información ingresada correctamente, incluidas las contraseñas anteriores, no se mostrará en ningún caso.

Nuestra desarrolladora principal nos ha dicho que es técnicamente posible si no se leen las entradas incorrectas, pero se siente extremadamente incomoda con la función y, por lo tanto, se ha puesto en espera mientras hacemos una lluvia de ideas.

El sitio web en cuestión es una aplicación amplia de mapeo / SIG que no presenta ninguna transacción monetaria en absoluto. Otras opciones de inicio de sesión / autenticación incluyen Google / LinkedIn / Twitter / facebook, por lo que obviamente no hay contraseñas para almacenar allí y el manejo es principalmente un problema de UX.

¿Qué vulnerabilidades de seguridad vienen con la implementación de esta característica? Nuestro cliente no carece por completo de conocimientos técnicos, por lo que una explicación general es suficiente.

Mis disculpas si la pregunta es demasiado amplia o la respuesta es muy obvia.

    
pregunta RaunakS 09.09.2016 - 20:35
fuente

13 respuestas

355

El problema principal es que las contraseñas incorrectas deben almacenarse de una manera que les permita ser mostradas posteriormente a los usuarios. Lo que, como señaló su desarrollador, significa que no pueden ser criptográficamente procesados primero. El resultado es que los almacena como texto sin formato (incorrecto) o cifrado (mejor, pero normalmente no se recomienda).

El mayor riesgo es si esta base de datos de contraseñas no válidas se vuelve accesible para los atacantes. O comprometen el servidor, realizan la inyección de SQL o lo recuperan de alguna otra manera. En lugar de descifrar las contraseñas principales, las cuales, con suerte, están fuertemente ocultas y, por lo tanto, son objetivos más difíciles, podrían decidir comprometer las cuentas utilizando la información del historial de contraseñas no válidas. O acceden fácilmente a las contraseñas de texto simple o intentan encontrar la clave de cifrado que les permite descifrar las contraseñas de texto simple.

Una fuente común de errores de inicio de sesión son los errores menores durante el proceso de ingreso de la contraseña. Así que mi contraseña es Muffins16 pero escribo mUFFINS16 porque mi bloqueo de mayúsculas está activado. O Muffins166 porque presioné la misma tecla dos veces. O Muffina16 porque mi dedo golpeó la tecla equivocada. Como puede ver, estas variaciones son lo suficientemente cercanas al original como para que los atacantes puedan determinar la contraseña válida de las contraseñas no válidas al intentar algunas modificaciones menores o comparar contraseñas incorrectas con palabras o nombres de diccionarios probables.

Este problema se agrava porque la mayoría de las personas usan opciones de contraseña similares a estos formatos y no cadenas aleatorias. Es más difícil para un atacante identificar el error tipográfico si su contraseña no válida es V8Az $ p4 / fA, aunque todavía es mucho más fácil probar variaciones de eso y luego adivinarlo sin ninguna información.

Otro riesgo es que los usuarios no recuerden cuál de sus contraseñas usaron en este sitio, por lo que intentan las comunes. Ahora, este sitio es repentinamente un objetivo más grande porque un atacante podría no solo comprometer la cuenta de un usuario allí, sino también en otros sitios con la útil lista de contraseñas "no válidas".

Puede mitigar algunos de estos riesgos borrando el almacenamiento de contraseñas no válidas inmediatamente después de mostrarlas luego de un inicio de sesión válido. Eso debería limitar la ventana de oportunidad para que un atacante acceda y se beneficie de los datos.

La pregunta que probablemente debería hacerle a su cliente es cómo predicen que los usuarios se beneficiarán al ver sus contraseñas no válidas. ¿Es así que los usuarios pueden identificar cómo escribieron mal su contraseña? Los errores tipográficos no son intencionales, por lo que no es probable que mostrarles su error mejore los intentos de inicio de sesión futuros. ¿Los usuarios pueden identificar a un atacante que intenta adivinar sus contraseñas? Se pueden proporcionar comentarios similares por fecha de lista, hora, IP / geolocalización u otra información para intentos inválidos sin el intento de contraseña. ¿Los usuarios saben que cometieron errores al ingresar la contraseña y no culpan al sistema de inicio de sesión del sitio? Este parece ser el único con mérito y no estoy seguro de que proporcione suficiente valor para justificar el riesgo.

Mi opinión es que una vez que entiendas mejor lo que están tratando de lograr con esta función, probablemente puedas sugerir alternativas más seguras.

    
respondido por el PwdRsch 09.09.2016 - 21:08
fuente
198

tldr; esto es incluso peor que no hashear tus contraseñas y almacenarlas como texto sin formato.

Estoy de acuerdo con las preocupaciones de su desarrollador principal. Para mostrar intentos de contraseña incorrectos en el pasado, debe almacenarlos de manera reversible, lo que significa que no se pueden hashear. Si alguien comprometiera el sistema, tendrían acceso a todos los malos intentos y probablemente podrían juntar cuáles son las contraseñas verdaderas para algunos usuarios. Por ejemplo, si puedes ver algunos de mis malos intentos fueron:

correct horrse battery staple
correct horse batttery staple

Sería bastante fácil averiguar mi contraseña real.

También estoy de acuerdo con respuesta de drewbenn : si escribo mi nombre de usuario incorrectamente pero con mi contraseña correcta, y el nombre de usuario incorrecto pasa a ser el nombre de otra persona, ahora ese usuario puede ver mi contraseña real.

    
respondido por el TTT 09.09.2016 - 21:03
fuente
94

Una vez intenté iniciar sesión en un sistema con mi contraseña pero el nombre de usuario de mi compañero de trabajo.

Luego, todas las veces que utilizo una contraseña incorrecta al intentar iniciar sesión en una cuenta compartida.

Y sé que a muchos administradores se les otorga acceso a la cuenta de su jefe para que puedan hacer las cosas. Me sorprendería mucho si sus jefes nunca hubieran ingresado la contraseña incorrecta y se hubieran distraído con un visitante antes de iniciar sesión correctamente para despejar el error.

Más todos los errores tipográficos cuando alguien está sobre mi hombro mientras estoy iniciando sesión.

Y en todos esos casos, a veces ingresé mi contraseña de Gmail o Lastpass en la solicitud de contraseña en el trabajo y viceversa.

Y la vez que busqué en Google mi contraseña porque no estaba mirando la pantalla y simplemente asumí que estaba bloqueada. No es que tenga algo que ver con tu propuesta, pero me gusta compartir esa anécdota porque les recuerda a las personas que todos pueden cometer errores y escribir algo a veces.

Lo único que hace esta característica de hUnt3r2 es convertir los pequeños errores (ingresar la contraseña incorrecta o escribirla incorrectamente) en exposiciones accidentales a una audiencia más amplia.

    
respondido por el drewbenn 09.09.2016 - 20:38
fuente
44

Pérdidas de reputación

La implementación de dicho mecanismo daría lugar a una pérdida de reputación inmediata, considerando que ha habido casos de alto perfil en los que los intentos fallidos de inicio de sesión se han utilizado para atacar otros sitios. Aquí hay un ejemplo:

  

Mark (Zuckerberg) usó su sitio, TheFacebook.com, para buscar miembros del sitio que se identificaron como miembros del Crimson. Luego examinó un registro de inicios de sesión fallidos para ver si alguno de los miembros de Crimson había ingresado alguna vez una contraseña incorrecta en TheFacebook.com. Si en los casos en los que ingresaron inicios de sesión fallidos, Mark intentó usarlos para acceder a las cuentas de correo electrónico de Harvard de los miembros de Crimson. Accedió con éxito a dos de ellos.

     

En otras palabras, Mark parece haber usado datos privados de inicio de sesión de TheFacebook para piratear las cuentas de correo electrónico separadas de algunos usuarios de TheFacebook.

Fuente: Cómo marca Zuckerberg hackeó Harvard Crimson

Una alternativa

Si su cliente está empeñado en mostrar intentos de inicio de sesión fallidos en el próximo inicio de sesión exitoso, como una especie de medida de bienestar, ¿puedo sugerir una alternativa? En lugar de mostrar las contraseñas fallidas, muestre la dirección IP y la información de geolocalización del navegador que envió la contraseña incorrecta. Debería ser bastante fácil de hacer, no causaría un problema de seguridad y proporcionaría información mucho más útil en caso de una actividad maliciosa real.

    
respondido por el John Wu 09.09.2016 - 23:39
fuente
39

Una razón no relacionada con la seguridad para no hacer esto: spam de inicio de sesión incorrecto.

Ejecuto mi lista de correos electrónicos / nombres de usuario contra tu aplicación. Intento iniciar sesión en cada cuenta con la misma 'contraseña'. Tal vez una frase ofensiva; lema político, o simplemente un anuncio para algún sitio web.

Luego, cada uno de sus usuarios inicia sesión, aquellos con los nombres de usuario / correos electrónicos que supongo que están obligados a mirar lo que ingresé.

Le da a cada persona anónima un vector para mostrar contenido a sus usuarios.

En el caso de compañeros de trabajo que cada uno usa el servicio y que probablemente puedan adivinar los nombres de inicio de sesión de otros, esto podría incluso resultar en acoso u otros problemas de recursos humanos en el lugar de trabajo.

    
respondido por el Joshua Hunter 13.09.2016 - 23:30
fuente
22

¿Qué sucede cuando quiero iniciar sesión en tu aplicación y estoy sentado con mi compañero de trabajo? Supongamos que escribo mal mi contraseña. ¿Ahora debo enviarlo lejos mientras inicio sesión para que no vea mi intento de contraseña?

    
respondido por el sixtyfootersdude 09.09.2016 - 23:22
fuente
17

Si hay usuarios con nombres de usuario / direcciones de correo electrónico similares, pueden intentar accidentalmente iniciar sesión en la cuenta de otro usuario.

Un usuario malintencionado podría usar su lista de intentos de contraseña "incorrecta" para ingresar a cuentas con nombres de usuario o direcciones de correo electrónico similares (por ejemplo, bill11, bill1, etc.)

Creo que sería mejor simplemente enumerar los intentos de inicio de sesión incorrectos y exitosos junto con la hora y la dirección IP relevante.

    
respondido por el webbster 11.09.2016 - 00:53
fuente
11

Estoy de acuerdo con otras respuestas que señalan que hace que sea más fácil adivinar la contraseña de un usuario si un atacante ha conseguido la lista de intentos fallidos.

Siendo ese el caso, no importa que su sistema no contenga ninguna información de transacción monetaria. Es común que los usuarios usen la misma contraseña, o variaciones en la misma contraseña, en múltiples sitios. Se les puede recomendar que no lo hagan, pero aún así sucede. Por lo tanto, el hecho de que no sienta que su sistema expone información confidencial en sí no significa que la información confidencial de sus usuarios no se ponga en riesgo si su sistema se ve comprometido.

Si el usuario de Joe usa la misma contraseña en su sistema que usa para su banco, si un atacante pudo adivinar su contraseña en su sistema y descubrió qué banco utilizó Joe, el atacante podría obtener acceso a la cuenta bancaria de Joe. O registros médicos, o cualquier otro sistema en el que Joe usó esa contraseña.

No solo estás protegiendo las contraseñas de tu sistema.

    
respondido por el Seth R 10.09.2016 - 00:17
fuente
9

Sospecho que su cliente sufre de un problema XY . Esto significa dar un paso atrás e intentar averiguar qué es lo que realmente quiere su cliente. A menudo es útil saber que alguien intentó una contraseña incorrecta y cómo se ingresó esta contraseña, no necesariamente cuál fue esa contraseña. Tal vez el cliente solo desee información suficiente para distinguir las amenazas benignas, como la manipulación de su propia contraseña, de las más sospechosas, como adivinar las contraseñas de la mitad del país en un dispositivo que nunca antes ha iniciado sesión.

Entonces pregunte a su cliente sobre el modelo de amenaza y vea si la siguiente información es suficiente:

  • ID de usuario para el cual falló la autenticación (para que pueda saber a quién avisar por cada falla)
  • fecha y hora
  • dirección IP del cliente, agente de usuario y geolocalización aproximada
  • si el cliente ejecuta JavaScript (los atacantes a menudo no se molestan)
  • si el cliente presentó una cookie por haber iniciado sesión correctamente en el pasado

Luego presente un cuadro de advertencia basado en esta información cuando un usuario inicie sesión correctamente después de uno o más errores.

    
respondido por el Damian Yerrick 12.09.2016 - 01:20
fuente
8

Una posible solución: dado que la preocupación aquí es sobre almacenar intentos de contraseña incorrectos en texto simple, evítelos. Cuando se establece la contraseña de un usuario, genere una clave pública y un par de claves privadas. Almacene la clave pública y la clave privada cifradas con la contraseña. Al registrar contraseñas incorrectas, cifrenlas con la clave pública (y añada sal). De esta manera, solo el usuario que conoce la contraseña correcta puede ver las contraseñas incorrectas.

    
respondido por el v7d8dpo4 10.09.2016 - 08:44
fuente
7

Dudo en agregar a las respuestas ya excelentes aquí, pero hay otro punto importante. A menos que esté absolutamente seguro de que los usuarios solo se conectan al sitio a través de HTTPS (y sinceramente, ni siquiera entonces) nunca debería tener la oportunidad de mostrar las contraseñas incorrectas ... ya que nunca deben transmitirse (cifradas o no) en el primer lugar. Los sistemas cliente solo deben transmitir algo como un hash con sal, no la contraseña real (en una implementación adecuada, para garantizar que el hash en sí no se convierta en la contraseña, es decir, algo que pueda ser robado y reutilizado), para evitar ataques de escuchas ilegales. / p>

Y no importa que el sitio no esté procesando transacciones financieras. Aún no quieres que se convierta en el eslabón más débil de alguna cadena.

Así que estoy completamente con su desarrollador principal en este caso. Estaría luchando con uñas y dientes contra esta "característica".

    
respondido por el Viktor Toth 11.09.2016 - 06:53
fuente
4

Su sistema tendrá una gran base de datos de contraseñas desencriptable. Buscando las contraseñas incorrectas para el usuario X, obtendrá casi las contraseñas correctas para la cuenta de X, las contraseñas correctas para las diferentes cuentas del usuario X, más las contraseñas correctas para las cuentas de los usuarios con casi el mismo nombre de usuario que X.

Con la suposición razonable de que un pirata informático podría ingresar en su sistema y obtener una copia desencriptada de la base de datos, esto sería perjudicial. Incluso suponiendo que el acceso a su sistema por parte de la persona equivocada no sea demasiado crítico, esa base de datos contendrá las contraseñas de sus usuarios para diferentes sistemas, lo que podría ser mucho más crítico.

    
respondido por el gnasher729 10.09.2016 - 17:21
fuente
0

Me parece que en una autenticación correctamente construida, la contraseña que el usuario escribió ni siquiera se transmite al sitio host, por lo que la cuestión de almacenar intentos incorrectos es discutible.

Puede ser aceptable tener una casilla de verificación "ver contraseña" en la interfaz, que es estrictamente una función local, y podría usarse como la contraseña se está escribiendo o después de un intento fallido. Probablemente la información guardada. debe limpiarse después de un corto tiempo para evitar que las contraseñas de recolección consolas abandonadas.

    
respondido por el ddyer 15.09.2016 - 20:03
fuente

Lea otras preguntas en las etiquetas