Yeah, I agree that aspect of it seemed quite problematic to me as well from the beginning. And he obviously cannot include the email in the hash. So it’s better to just disallow the top x most common passwords, which we already have. (Though it’s not updated on the fly as the list changes over time.)
2 Me gusta
What would really solve the issue here, in my humble opinion, would just to apply best practices like preventing an IP to try to login more than X times without success, don’t let people try passwords at non human time ( humans don’t try a password every 1 sec ) would fix the security issue without forbidding all the passwords.
The way I see is, someone can make a list that gives all the combinations of A-Z 1-9 up to X length. This means nothing if you can’t brute force the target, unless it’s a targed attack and then there’s not much you can do.
Is anything like that currently implemented?
Yes, there is extensive rate limiting across the whole of Discourse. By default login attempts are limited to 6 per minute and 30 per hour (per IP).
9 Me gusta
Hmm, can you extrapolate here though? It would seem to me that the distribution of lengths might be quite different if you focus on the 1 mil most common ones since those will obviously tend to be shorter.
1 me gusta
I think it’s a good idea to alert the user but maybe not prevent them from using the password if they insist. Explain it better, maybe something along the lines of
“The encrypted version of this password has been found in a public database of stolen user information and may put your account at increased risk of being hacked by brute force attacks. If you use this password across multiple web services we strongly recommend changing them to unique passwords to stay secure, especially for mail accounts.”
And let them hit submit a second time to use it anyway.
hopefully webauthn will make passwords a thing of the past someday 
2 Me gusta
Esto no tiene sentido para mí (de ahí que haya elevado el hilo): una vez que se sabe que una contraseña ha sido descifrada (o encontrada en texto plano), es significativamente menos segura. Esto representa una enorme disminución en la entropía, incluso con supuestos muy permisivos:
- una contraseña aleatoria de 10 caracteres, incluso con un conjunto de caracteres muy limitado (ejemplo de hombre de paja: solo letras minúsculas: Pr = 1/26^10 = 1/1,4e14)
- una contraseña que se sabe que aparece en la lista de HIBP (Pr = 1/5e8)
En el instante en que otra persona la usó y además fue comprometida y/o descifrada —esa es la diferencia crucial.
¿Cuál es el problema práctico con evitar una contraseña que solo ha aparecido en una lista? Como usuario, definitivamente me gustaría saberlo para evitar volver a usar esa contraseña. Como administrador de un sitio, no quiero que mis usuarios utilicen contraseñas comprometidas. Esto parece valer muy bien la compensación en usabilidad.
No, no es una diferencia crucial porque estadísticamente todas las contraseñas serán vulneradas con el tiempo.
Recuerda que ya bloqueamos el millón de contraseñas más comunes desde hace años, por lo que ya estás protegido en los aspectos que realmente importan.
3 Me gusta
Estadísticamente, todos los algoritmos de criptografía y hash serán rotos con el tiempo. Cuando aparece el primer indicio de que un algoritmo está cerca de ser roto, dejamos de usarlo.
¿Por qué deberían ser diferentes las contraseñas? Toda la seguridad es una apuesta de que la entropía utilizada es suficiente para la tarea dada, y siempre hay una suposición sobre la longitud o intensidad del ataque que se puede soportar.
Dado que se pierde al menos 6 órdenes de magnitud de entropía la primera vez que una contraseña aparece en una lista (en la realidad, probablemente varios más), esto parece una decisión sencilla.
Sí, esta es una situación mucho mejor que la que existe con muchos otros paquetes de software disponibles hoy en día. HIBP sigue siendo una buena mejora para los sitios que desean más garantías además de eso.
Parece una oportunidad para un botón de «Generar frase de contraseña» mediante un complemento, si eso es técnicamente viable…
Se excluiría cualquier cosa de la lista de comprometidas y el usuario podría optar por crear la suya propia, que ya incluye la lista de exclusión «básica» de 1 millón. El método del botón permite omitir la necesidad de educar al usuario sobre las listas de comprometidas y la entropía, temas para los que generalmente no tendrán tiempo.
Aunque, en mi opinión, Discourse ya lo hace bastante bien.
¿Por qué generar la contraseña en el servidor?
Asumiendo que el usuario necesita guardarla, ¿no tendría más sentido que el usuario asuma la responsabilidad de generar la contraseña? Es muy probable que su gestor de credenciales preferido ya lo haga.
2 Me gusta
Porque podría ser mejor que seguir diciéndoles constantemente que “apple”, “apple1”, “apple 123”, “apple 12345” no son aceptables según la lista de 1 millón de contraseñas prohibidas. Personalmente, no esperaría mucho esta función en Discourse, pero si permite manejar el tema de las contraseñas comprometidas de manera más elegante y deja en manos del usuario la responsabilidad si algo sale mal, podría valer la pena considerarlo.
¿Y estás sugiriendo que los gestores de contraseñas del lado del cliente generarán contraseñas como esta?
Abogar por que tus usuarios utilicen un gestor de contraseñas será mucho más efectivo que imponer una contraseña desde un solo sitio. Lo segundo solo llevará a que la usen en todas partes y acelerará su compromiso.
Arreglar la estupidez es más difícil que reparar lo que ha sido comprometido; mantenerse de la mano con algo similar a https://www.useapassphrase.com/ les da un hueso a quienes no están interesados en los aspectos académicos, en mi opinión.
He construido sistemas utilizados por decenas de millones de personas y hemos probado diversos enfoques relacionados con las contraseñas, incluidos esos horribles requisitos de que deben contener x e y.
A menos que eduques a los usuarios sobre la gestión de contraseñas, solo aumentarás la probabilidad de fatiga por contraseñas, su reutilización y el temido “post-it debajo del teclado”.
Generar contraseñas en el servidor también crea un nuevo vector y superficie de ataque que debe protegerse. Personalmente, podría prescindir de TODO lo anterior.
3 Me gusta
Habría pensado que JS generaría una frase de contraseña aleatoriamente en el cliente, luego la hash y la compara con una lista. La parte educativa puede ser un stub encima de “Crear contraseña”. En realidad, no creo que nada de esto sea algo de lo que Discourse deba preocuparse, pero mientras la gente atribuya erróneamente su propio comportamiento a la marca, podría valer la pena considerarlo.
Creo que tu mejor opción, entonces, es desarrollar o encargar un plugin que haga lo que sugieres.
1 me gusta
Eso es exactamente para lo que sirve este complemento.
He reflexionado sobre esto un poco desde que escribí este complemento y acabo de coincidir con Jeff.
“Vulnerado” significa que hubo alguien, en algún lugar, que pensó en esa frase que apareció en “una lista”. Imagina si alguien creara una herramienta que:
- Hiciera pública una lista de cadenas.
- Generara y añadiera sistemáticamente cadenas únicas a la lista.
El argumento de Jeff es que esto significa que, eventualmente, todas las cadenas serán “inseguras” porque aparecerán en alguna lista pública en algún lugar y, con el tiempo, tu contraseña “supersegura” también aparecerá en esta lista en constante expansión.
Toda la idea de las contraseñas en sí mismas solo se basa en la “imposibilidad estadística” de que alguien no pueda adivinar la contraseña de tu cuenta. Técnicamente, un atacante no necesita conocer una contraseña; solo necesita hacer un verdaderamente buen intento. Pueden inclinar la balanza a su favor definiendo lo que significa hacer un “buen intento”:
- Si tienen una filtración, prueben la misma contraseña para la misma cuenta.
- Si tienen una lista de filtraciones, prueben las contraseñas que muchas personas usan.
Ya hemos discutido cómo Discourse es bueno en el punto #2 anterior. Creo que lo que estás tratando de abordar es el #1, pero sería innecesario y una pesadilla de usabilidad tener algo así en el núcleo (asumiendo que ninguna contraseña, no vinculada al nombre de usuario, debería usarse)… Pero si quieres lo que describes para tu sitio, este es el complemento para ti.
4 Me gusta
Sí. Francamente, este es un argumento terrible porque está completamente desconectado de cualquier noción de probabilidad, que es la única forma correcta de razonar sobre esto.
Afortunadamente, estamos hablando de un caso excepcional que aparece después de descartar las contraseñas más utilizadas, lo cual ya es por sí solo una estrategia bastante buena.
1 me gusta