¿Cómo verificar si hay contraseñas duplicadas?

Las únicas formas prácticas de hacerlo son usar la misma sal para cifrar todas las contraseñas (malas) o almacenar las contraseñas en texto sin formato o cifrado reversible (muy, muy mal).

Dado que esos enfoques son problemas de seguridad grandes y mayores, supongo que Google no está haciendo ninguno de los dos. Lo que podrían estar haciendo es rechazar las 1.000 o más contraseñas más comunes. Aquí hay una lista de contraseñas comunes: enlace (tenga en cuenta que si no permite las 10.000 principales para la usuario "ordinario", ha rechazado todo.)

Editado para agregar: Supongo que podría almacenar las últimas contraseñas de n y sus (diferentes) sales. Parece un montón de problemas.

Si está almacenando las contraseñas correctamente, es decir, con PBKDF2 / BCrypt / SCrypt, entonces, a medida que el usuario cambia su contraseña, puede dedicar tiempo a codificarla con las sales de otros usuarios (que son, por supuesto, criptográficamente aleatorias y únicas por usuario), y si encuentra una coincidencia en la primera N, dígale al usuario que no. Si quisiera, podría verificar todos los usuarios, pero eso requeriría una cantidad prohibitiva de tiempo de procesamiento.

• Si no toma una cantidad prohibitiva de tiempo de procesamiento, o solo tiene un puñado de usuarios o necesita aumentar su PBKDF2 / BCrypt / SCrypt iteration count / factor de trabajo.

Esta es una BAD idea , sin embargo, ya que le brinda al usuario A la posibilidad de obtener información sobre lo que otros usuarios tienen como contraseña, sin intentar realmente iniciar sesión como ellos.

Mejor, incluya un chequeo contra los ataques de diccionario basados en reglas con un diccionario de pequeño a mediano, usando esa contraseña candidata de texto no cifrado pre-hash. Entro en más detalles en mi respuesta a , pero los conceptos básicos son:

• Tenga una lista de palabras pequeña a mediana, muy simple, las letras son mayúsculas.

• Codifique algunas "reglas" para aplicar a la contraseña, como Hashcat o John the Ripper

  • Puede manejar todas las reglas en mayúsculas / minúsculas con un simple UPPER () equivalente y un diccionario en mayúsculas, si lo encuentra, es débil. (JacQueLinE)
  • Anexar / anteponer números solo para cumplir con los mínimos de longitud es una simple coincidencia de patrón: si los últimos / primeros N son números y la longitud restante no es suficiente, es débil. (Riddick123)
  • Quite los números N del principio / final, en mayúsculas y verifique el diccionario para el resto (JacQueLine12)
  • Los números y / o símbolos anteriores, pero N-1 (# 1JacQueLine)
  • Los formatos de fecha, pero anteriores. (JacQueLine02121995)
  • Si los últimos / primeros N-1 caracteres son números y el último / primero es un símbolo, y la longitud restante no es suficiente, es débil. (! JacQueLine1)
  • Eliminar un carácter a la vez, ver si coincide con el diccionario. (jacqu $ eline)
  • Combina algunos de estos.
  • Revertir todos estos.
  • luego continúe con las combinaciones de palabras del diccionario y así sucesivamente.

Rechazaría las peores contraseñas, absolutamente. Para un proyecto avanzado, comience con una verificación "peor" (pequeñas contraseñas peores en la N más altas + reglas muy básicas), y simplemente rechace esas. Luego, si no se produce ninguna coincidencia, intente una comprobación "de peor nivel" y emita una gran advertencia roja brillante. Luego, si no se produce una coincidencia, intente realizar una comprobación "peor" y envíe una advertencia más pequeña.

Si no se produce ninguna coincidencia, no digas nada. Puede que aún sea una contraseña horriblemente mala, simplemente no comprobó esa combinación particular de palabra base + regla; nunca se puede saber si una contraseña es buena.

• Ejemplo: "286755fad04869ca523320acce0dc6a4" parece bastante aleatorio! Es solo MD5 ("contraseña") !!
  • Hacerlo hablar 1337 no ayuda.

Si los usuarios tienen acceso a los hashes de contraseña y a las sales, entonces pueden ejecutar herramientas como Hashcat o John the Ripper como cualquier otra persona con una lista de contraseñas (filtrada).

Si usa algo como un filtro Bloom, puede realizar una prueba para ver si alguno de sus otros usuarios ya está usando esa contraseña, pero sería difícil saber qué usuarios en particular. Existe la posibilidad de falsos positivos pero no falsos negativos.

enlace

De acuerdo con la otra respuesta, si bien es posible que sea una mala idea, ya que proporciona información sobre las contraseñas que ya se han utilizado.

Soy escéptico acerca de si esta es una protección valiosa. Ciertamente, evita que una gran cantidad de personas utilicen "abcdef" y "123456", pero si 10 de sus usuarios 1M eligen una contraseña segura, aleatoria y larga, ¿cuál es el daño si utilizan el mismo valor?

Tengo una solución parcial a tu pregunta original. De uno que recibí, su intención es verificar si un número determinado de personas está usando las mismas contraseñas.

Las respuestas aquí hasta ahora parecen ir más en la dirección de contraseñas seguras, lo cual es bueno. Si bien debe garantizar contraseñas 'seguras', creo que simplemente no desea que un cierto número de personas use la misma contraseña, por muy segura que esté.

¿Qué pasa si haces esto? Mantenga una lista de hashes simples sin sal de las contraseñas de los usuarios en el momento del registro. Como un hash SHA-512. (Incluso podría hacer repetidos hashes un cierto número de veces que solo usted sabe) La lista no tiene nombres de usuario, solo hashes de contraseña que pueden ser de cualquiera. Incluso podría ir más lejos e implementarlo en una tabla, de modo que este hash de aceptación previa tenga un contador al lado, que muestre el número de personas que utilizan una contraseña específica en su sitio. Tenga en cuenta que no hay forma de decir la contraseña original.

Por supuesto, cuando en realidad está almacenando el nombre de usuario / contraseña en la base de datos, saldrá un hash. La lista mencionada es solo una lista aleatoria de hashes de contraseñas presellados junto con el número de veces que se ha generado el hash.

Ahora, cuando un nuevo usuario elige una contraseña, realiza el hash previo a la aceptación y comprueba si ese hash ya está en la lista y, de ser así, ¿cuántas veces se ha utilizado el hash? Si se ha utilizado hasta el número máximo de veces que ha decidido, simplemente rechace la contraseña. Al ingresar una contraseña "exitosa", ingrese el nuevo hash preenselado en la lista.

Idealmente, si los usuarios utilizan contraseñas "seguras" siguiendo los criterios que otras personas han mencionado, el contador de cada hash en la lista debería ser exactamente 1.

La solución es segura, ya que incluso si un atacante roba la lista, no puede usar el hash para iniciar sesión, ya que no es lo mismo que el hash salado real en la base de datos. También puedes usar diferentes algoritmos de hashing para frustrar el cracking. Esto, por supuesto, no significa que el atacante no pueda probar los medios habituales que otros han mencionado. Lo que estoy diciendo es que esta solución no compromete en modo alguno la seguridad de sus usuarios.

El inconveniente (y por qué dije que es una solución parcial) es que si el mismo usuario cambia su contraseña 3 veces al día, la lista se modifica con el hash de presa de cada una de esas contraseñas, aunque en La realidad, nadie está usando ninguno de ellos. Y no hay forma de verificar quién suministró qué hash como lista, por razones obvias, no contiene nombres de usuario. Es muy anónimo, y debería ser!

En realidad, hay una solución a la baja, pero creo que es mejor dejarlo sin mencionar. ¡Déjame saber lo que piensas! Gracias y que Dios te bendiga.