¿Prohibir contraseñas específicas?

La teoría es que te gustaría ejecutar las mismas herramientas que el atacante. El atacante ejecutará una lista de "contraseñas probables" basadas en lo que sabe o adivina de la psicología de los usuarios. John the Ripper es un conocido software de descifrado de contraseñas que incluye muchas "contraseñas habituales" y reglas comúnmente empleadas por los usuarios para derivar contraseñas ingeniosas.

Su ventaja es que el código del servidor tiene acceso a la propia contraseña cuando el usuario se registró. Contrariamente al atacante que debe ejecutar cada intento a través de un proceso de hashing potencialmente costoso (y puede ser pesado si arranca el bcrypt la iteración cuenta a su máxima potencia), su código puede funcionar en las cosas reales y hacer algunas optimizaciones como, como sugiere, la normalización a minúsculas.

Sin embargo creo que esta no es una muy buena idea en general. El atacante no está restringido a software abiertamente disponible; puede ajustar su lista de contraseñas potenciales al objetivo real (por ejemplo, utilizando más derivaciones alrededor de los nombres de los hijos del usuario específico cuya contraseña está bajo el fuego del atacante). Incluso mantenerse al día con la lista de "contraseñas débiles comunes" es probable que sea un proceso agotador. Además, el propio usuario entrará en el juego: dado que las restricciones de contraseña se sienten como un obstáculo molesto para los usuarios, utilizarán toda su creatividad para encontrar reglas de generación de contraseñas aún más ingeniosas que evaden sus pruebas.

Hacer cumplir las complejas reglas de exclusión de contraseñas en el servidor es, de alguna manera, luchar contra el atacante en su campo de batalla, y traerá al usuario a la fiesta; el usuario puede desafortunadamente (y sin querer) ayudar al atacante.

Por lo tanto, recomendaría contra tales reglas. Lo que necesita es la colaboración del usuario, y lo tendrá siendo transparente sobre las reglas que emplea; el usuario debe poder encontrar una contraseña que "pase su prueba" sin ingresar un proceso de prueba y error. Nada es más molesto que elegir diez contraseñas sucesivas hasta que finalmente un servidor rígido las acepte. No quieres molestar al usuario, porque un usuario molesto ayudará a los atacantes (no lo pensará así, pero ese es el efecto neto). Las reglas explícitas ("al menos 8 caracteres, al menos 1 dígito") son mucho mejores para la pedagogía.

Y, por supuesto, nada es mejor que la educación y capacitación adecuadas de los usuarios sobre los peligros de las contraseñas no aleatorias.

Suena bien además de otras prácticas sanas (por ejemplo, bcrypt).

Yo usaría una lista negra de contraseñas lo más grande posible. Si su contraseña está en una lista divulgada de 100000 contraseñas (o solo es diferente de una contraseña en esa lista por uno o dos caracteres), es una contraseña incorrecta y las GPU probablemente puedan anularla. También es posible que alguien esté reutilizando esa contraseña. La única buena razón para relajar este criterio es si no quiere frustrar a sus usuarios que pueden recurrir a un competidor que permita contraseñas débiles. (También para indicar lo que es obvio, no utilice contraseñas de sus propios sistemas para crear esta lista de contraseñas en la lista negra, ya que está almacenando la contraseña en texto simple y un gran no).

Además, es posible que desee crear una función de sugerencia de contraseña que siempre genere una contraseña que supere sus criterios y que aparezca una ventana emergente cada vez que se produzca un error. (Aunque todavía es necesario que el usuario lo escriba dos veces).

También me aseguraría de que su esquema no impida inadvertidamente frases de contraseña seguras. Por ejemplo, fork scorn loss cope endow yin es una excelente frase de contraseña creada aleatoriamente y no debería prohibirse si una de las contraseñas comunes de la lista negra se reduce a fork (y la bifurcación está incluida en su frase de contraseña).

De hecho, Jeff Atwood aboga por esta práctica exacta en su publicación del blog: enlace

En su rol con Discourse, recomendó imponer una longitud mínima de 10 caracteres, y luego verificar las coincidencias con las 10,000 contraseñas más populares con más de 10 caracteres.

Consulte la publicación del blog para conocer otras buenas recomendaciones.