¿Puedo usar de manera segura mis propias estadísticas para evaluar la seguridad de la contraseña en el número de veces que se usa una contraseña?

0

Supongamos que quiero dar a mis hipotéticos usuarios de 10mio usuarios una buena retroalimentación sobre la seguridad de su contraseña. Además de las pruebas de entropía clásicas y la lista top500 de contraseñas malas, es posible que desee que se base en "ya hay más de N usuarios con la misma contraseña" (para N quizás 100).

Aparte de las cosas de contraseña de hash hash multiround salted de vanguardia, almaceno ingenuamente una tabla grande con contraseña: pares de contador (y la mantengo a través de cambios de contraseña) y le digo al usuario que su contraseña es mala cuando llega ese contador N. Ahora, por supuesto, esto derrota a mi buena administración de hash de contraseñas: quien obtenga esa tabla tiene todas las contraseñas posibles y puede probarlas de forma trivial. Podría hacerles un hash, lo que simplemente agregaría un factor de tiempo demasiado pequeño para estar seguro.

Entonces, ¿cómo puedo (si es que lo hago) mantener cualquier estadística que me permita tener estos contadores (o algo lo suficientemente similar sin demasiados falsos positivos) sin que los datos estadísticos sean más un riesgo de seguridad cuando se exponen que la tabla? de hashes de contraseña?

    
pregunta PlasmaHH 23.07.2014 - 14:30
fuente

3 respuestas

3

Como señaló @aviv, revelar a un usuario que otro usuario también tiene la misma contraseña es un problema.

Si realmente pretende mantener tales estadísticas, entonces tiene otro problema inherente: el "motor de estadísticas" solo puede ayudar a cualquier atacante, ya que genera una lista de contraseñas que están en uso. Incluso una forma reducida que simplemente dice "esta contraseña ya está siendo utilizada por otra persona" permite al atacante romper las contraseñas mucho más rápido, por la siguiente razón. El buen hashing de contraseñas usa sales para que los atacantes no puedan intentar romper 10 millones de contraseñas en paralelo. Si el hash no tiene sal, el atacante puede hashear una contraseña potencial una vez , y comparar el valor de hash resultante con los 10 millones de hashes; De esa manera, el atacante rompe 10 millones de contraseñas por el costo de romper una. Las sales impiden eso. Las sales son buenas.

Ahora suponga que tiene un motor de estadísticas que le puede decir, cuando un usuario ingrese su nueva contraseña, si esa contraseña ya la está usando otra persona (incluso sin decir cuántos usuarios la han elegido). Luego, un atacante, que podría obtener una copia de su base de datos (las contraseñas de hash, precisamente porque teme ese escenario), puede ejecutar el mismo "motor" en sus propias computadoras. Por lo tanto, puede "enviar" una contraseña potencial al motor y saber si la utiliza uno de los 10 millones de usuarios o no. Esto le permite recortar su enorme lista de contraseñas potenciales a las que realmente valen la pena: en lugar de probar mil millones de contraseñas en cada valor de hash, probará solo las más o menos 1000 contraseñas para las que obtuvo resultados de las estadísticas. motor. Acabas de hacer la tarea del atacante un millón de veces más fácil.

La única forma de salir de este problema es asegurarse de que el atacante nunca podrá acceder a las estadísticas (lo que, a su vez, implica que no serán mostrados a los propios usuarios). Esto sugiere lo siguiente:

  • Cuando un usuario elige su contraseña, la contraseña se revisa como de costumbre (con bcrypt o algo similar).

  • La contraseña está también cifrada asimétricamente con una clave pública RSA dada. El cifrado asimétrico es aleatorio, por lo que los resultados cifrados no permiten ataques de diccionario. Una clave RSA de 2048 bits es suficiente para cifrar elementos de datos de hasta 245 bytes, lo que debería ser suficiente para las contraseñas.

  • La clave privada correspondiente se mantiene en una máquina offline (por lo tanto, presumiblemente inmune a los ataques remotos). A intervalos regulares, el "oficial de estadísticas" recopila las contraseñas cifradas del servidor, las transfiere a la máquina fuera de línea (con una unidad USB o algo similar), las descifra y ejecuta las estadísticas.

respondido por el Tom Leek 23.07.2014 - 15:11
fuente
2

No creo que quieras hacer eso en absoluto ... darás pistas sobre las contraseñas de otros usuarios. Si recibo el mensaje de que otro usuario está usando mi contraseña, ahora tengo información valiosa. Incluso podría saber o adivinar quién es ese usuario si tengo algún conocimiento previo sobre él

    
respondido por el aviv 23.07.2014 - 14:43
fuente
0

NO debe poder determinar si algún usuario tiene las mismas contraseñas dada la información en su base de datos. Es solo un riesgo de seguridad por diseño.

Si realmente quiere hacer algo como eso, al menos nunca le diga al usuario la razón, solo diga algo como "Su contraseña no es lo suficientemente compleja" junto con el genérico inferior / superior / dígito / cheque especial.

    
respondido por el Dillinur 23.07.2014 - 17:45
fuente

Lea otras preguntas en las etiquetas