¿Por qué los requisitos de contraseña estática se utilizan con tanta frecuencia?

Después de la famosa tira XKCD , se iniciaron algunos proyectos para tratar exactamente este tipo de verificación de entropía. Uno de estos fue el verificador de contraseña ZXCVBN , realizado por un empleado de Dropbox.

Es posiblemente el comprobador de contraseñas más completo de su tipo. Verifica los patrones, las palabras y más, agregando (o restando) una puntuación de entropía en consecuencia. Es explicado en detalle en su blog .

Esta es una gran idea, de hecho, es la única forma correcta de medir la seguridad de la contraseña.

¿Pero cómo mediría la entropía de la contraseña?
La entropía es un aspecto del proceso de generación, no de la salida.

Por ejemplo, ¿cuál sería la salida de tal medida para Tr0ub4dor&3 ? Por cualquier medida razonable de posible entropía basada en una contraseña dada, sería bastante decente: más de 70 bits de entropía. O tal vez, teniendo en cuenta un supuesto proceso de generación de contraseña , podría ser lo suficientemente inteligente como para darme cuenta de que en realidad tiene un límite de solo 28 bits. , ya que cada carácter no se selecciona al azar, pero primero se selecciona una palabra completa. Pero en realidad debería descartar toda esta idea, ya que obviamente simplemente la copié directamente de ese cómic.

El mismo problema se aplicaría si la contraseña fuera correct horse battery staple (una de las contraseñas más populares entre una cierta población).

Entonces, sí, los requisitos de contraseña deben basarse en la entropía de la contraseña, pero no se puede aplicar este requisito a una contraseña determinada después del hecho.

(Por cierto, como mencioné en otra respuesta sobre este tema (desde una dirección diferente), podría Ser una buena idea implementar un sistema donde las contraseñas / frases de contraseña se generen automáticamente para un determinado nivel de entropía y se proporcionen al usuario, en lugar de pedir a los usuarios que encuentren uno que cumpla con nuestros requisitos. Por supuesto, esto es lo que un buen administrador de contraseñas haría en el cliente, de todos modos ...)

Las políticas de contraseña estática se eligen por dos razones principales: la usabilidad y el cuerpo de investigación que demuestra una efectividad aceptable. La mayor parte de mi respuesta proviene de el excelente trabajo de investigación en un medidor avanzado de seguridad de contraseñas, Telepathwords.

Primero, para resumir algunas de las investigaciones utilizadas para respaldar las políticas de contraseña actuales:

  

Las reglas de composición de contraseñas se remontan al menos a 1979, cuando Morris y   Thompson informó sobre la previsibilidad de las contraseñas utilizadas por los usuarios.   en sus sistemas Unix; Propusieron que las contraseñas de más de cuatro.   caracteres, o contraseñas puramente alfabéticas de más de cinco   Los personajes serán "muy seguros" [19] [Sin embargo ] Bonneau   Analicé casi 70 millones de contraseñas en 2012, 33 años después, para   medir el impacto de un requisito mínimo de seis caracteres comparado   sin el requisito [2] . Encontró que casi no hacía diferencia en   seguridad ...

     

Esto incluye el trabajo de Komanduri et al. [13] y Kelley   et al. [12] , quienes utilizaron diseños de estudios similares para realizar comparativos   Análisis de reglas de composición de contraseñas. Estos estudios previos encontraron que   el aumento de los requisitos de longitud en las contraseñas generalmente llevó a   contraseñas utilizables que también tenían menos probabilidades de ser identificadas como débiles   por su algoritmo de adivinación [ 13 12 ]. Más recientemente, Shay et al.   estudió las políticas de composición de contraseñas que requieren contraseñas más largas,   encontrando el mejor rendimiento vino de mezclar un mínimo de 12 caracteres   con un requisito de tres conjuntos de caracteres [25] .

La usabilidad es una razón enorme por la que criterios más complejos como la entropía de contraseñas no se usan con más frecuencia:

  

En un estudio sobre la distribución de políticas de contraseñas, Florencio y   Herley encontró que los imperativos de usabilidad parecían jugar al menos como   una función importante como seguridad entre los 75 sitios web examinados [8] . ...

     

Ur et al. También se estudió el efecto de los medidores de fuerza de contraseña en   creación de contraseña. Ellos encontraron que cuando los usuarios se frustraron y   perdió la confianza en el medidor, aparecieron contraseñas más débiles. [28] ...

     

Mientras que [Dropbox] zxcvbn proporciona una mejora muy necesaria en el   credibilidad de sus estimaciones de fuerza en comparación con los enfoques   basándose únicamente en las reglas de composición, es poco probable que esta credibilidad   ser observado por los usuarios. De hecho, su credibilidad percibida puede sufrir si   usuarios, a quienes se les ha dicho que agregar caracteres aumenta la contraseña   fuerza, ver las puntuaciones disminuyen cuando se agregan ciertos caracteres. por   Por ejemplo, cuando se escribe iatemylunch, la estimación de la fuerza disminuye desde   la segunda mejor puntuación (3) a la peor puntuación (1) cuando la final   Se agrega el caracter. Incluso si los usuarios encuentran las estimaciones de fuerza de zxcvbn   creíbles, es poco probable que entiendan el subyacente   mecanismo de estimación de la entropía y, por lo tanto, no estar seguro de cómo mejorar su   puntuaciones. [30]

Finalmente, para completar, debemos darnos cuenta de que definir la entropía en este ejemplo es muy difícil (pero está lejos de ser imposible). Podemos hacer muchas suposiciones diferentes sobre la sofisticación del algoritmo o diccionario de adivinanzas de un cracker de contraseñas, y todo esto conduce a respuestas diferentes en la entropía de contraseñas como " Tr0ub4dor & 3 "o" corrija la batería del caballo correcto ". Las medidas de entropía de contraseñas más sofisticadas se basan en diccionarios de millones de contraseñas y estudios avanzados de patrones de contraseñas, y este nivel de sofisticación es difícil de lograr para muchos administradores (y piratas informáticos).

La entropía se calcula en función de cómo se crea una contraseña. Para calcular la entropía, no es necesario que conozca la contraseña , sino que debe saber cómo se creó. Tener la contraseña no le ayuda a calcular la entropía, solo le permite hacer una estimación muy pobre de la entropía.

Ejemplo:

Contraseña123

Si nuestra contraseña "Password123" fue elegida de una lista de las 3 contraseñas más utilizadas que contienen letras, números, mayúsculas y minúsculas, y tienen más de 10 caracteres, la entropía de Password123 es ridículamente baja.

Si la misma contraseña "Contraseña123" fue elegida por un generador aleatorio perfecto que crea contraseñas de 11 dígitos con cada dígito elegido entre 5000 posibles puntos de código Unicode, la entropía de Contraseña123 es ridículamente alta.

En otras palabras: estás en algo, pero "entropía" es la palabra incorrecta, "entropía" ya tiene un significado diferente. Lo que estás buscando es la "fuerza" de una contraseña. Y la fortaleza de una contraseña es difícil de medir correctamente, e incluso más difícil de comunicar. El hecho de que la fuerza cambie siempre que cambien los métodos de ataque tampoco ayuda.

No puede medir la entropía de la contraseña, solo puede medir un límite superior para la contraseña. Por lo tanto, cualquier estimador de fortaleza de contraseña es defectuoso.

El uso de un estimador de contraseñas o las reglas molestas tienen el mismo efecto de hacer que el usuario intente cumplir con los requisitos mientras mantiene la contraseña lo más fácil posible para que la recuerden. Entonces, cuanto más difícil sea el requisito, más difícilmente intentarán construir una contraseña fácil de recordar. Por ejemplo, utilizando contraseñas como Pa $$ word1 o passwordpasswordpassword. El problema es que una contraseña fácil de recordar también es una contraseña fácil de adivinar.

Cuando el servicio que presta es opcional, también tiene el riesgo de alienar a los usuarios con requisitos demasiado estrictos y perder clientes.

Sin embargo, puede imponer un límite inferior de 10 caracteres, ya que todas las contraseñas de menos de 10 caracteres son débiles y el requisito no es demasiado difícil de cumplir. También puede darles consejos para construir contraseñas seguras.

Para su última pregunta "¿Algún sitio o programa ya incorpora dichos requisitos de contraseña?", supongo que puede encontrarlos. Sin embargo, no recomendaría seguir su práctica. No es porque alguien más lo haga, es una buena idea hacer lo mismo.

¿Cómo se mide la contraseña "entropía"?

Es imposible.

Una contraseña como "hresda" puede tener 'baja entropía' porque se eligió entre letras minúsculas, pero si se generó al azar a partir de un conjunto de caracteres que contienen letras mayúsculas / minúsculas, dígitos y símbolos y el resultado acaba de pasar para contener solo letras minúsculas, luego tiene una entropía más alta. Una contraseña como "A63ba!" puede tener una entropía más baja que "hresda" si se generó específicamente como [mayúsculas] [dígitos] [dígitos] [minúsculas] [minúsculas] [símbolo] en lugar de elegirse al azar.

Sí, hay programas que miden la entropía de una contraseña para decidir si es lo suficientemente bueno o no. Una vez que dicho programa es Wabol Talk . La función se implementa mediante el uso de estimate_quality en el módulo principal del programa. En última instancia, el método se utiliza en el método que se encuentra justo por encima de él ( error ) para validar los campos de contraseña que se utilizan para generar claves y vectores de inicialización. La estimación es solo de calidad mínima, ya que no juzga las contraseñas en función de su frecuencia de uso, pero demuestra una de las formas más sencillas de encontrar cuántos bits de entropía están presentes en una contraseña.

Una nota sobre el entorno internacional. Si la contraseña se crea para un sitio web abierto a todo el mundo (no es infrecuente), es probable que el usuario no hable inglés como idioma nativo y, en cambio, pueda elegir, digamos, palabras suecas como base para el método de creación de contraseñas xkcd.

"paraplyost" (queso paraguas) probablemente ocuparía un lugar más bajo en un verificador de entropía que sabía sobre el diccionario sueco que uno que no. Si un atacante sabe que el usuario es sueco (no es el escenario más común, pero puede suceder), podría hackear la contraseña de un usuario más fácilmente de lo que el verificador de entropía, a menos que el verificador de entropía esté cargado con cientos (o miles). ?) de los diccionarios.

Un efecto secundario agradable de esto es que si usted habla un idioma que no es uno de los más comunes en el mundo, puede crear contraseñas aún más seguras como usuario anónimo en un sitio web internacional. :)

  

¿Algún sitio o programa ya incorpora dichos requisitos de contraseña?

Varios sitios web hacen eso. Por ejemplo, vaya a enlace e intente registrarse con una contraseña que es una palabra común del diccionario de 8 caracteres o más (por ejemplo, dictionary ). Verás que el medidor de fuerza te muestra la puntuación más baja. Ahora intente mezclar las letras al azar (por ejemplo, ioictnadry ) y use eso: verá que el medidor de fuerza aumenta.

El inconveniente obvio de este método es que necesita cargar un diccionario de contraseñas comunes a cada cliente mediante el formulario de inicio de sesión. Esto recientemente se convirtió en correcto, pero fue totalmente inaceptable hace 5 o 10 años.

Mi impresión es que la mayoría de las grietas usan word & listas de contraseñas Y algunas variaciones en ellos, como sumar números o repetir una palabra. Excepción señalada a continuación.

Por lo tanto, una contraseña también es débil si aparece en una lista , por muy fuertes que sean los cálculos de entropía (del proceso de generación). En el significado de 'una lista': si la lista del cracker no contiene su contraseña, es fuerte, a pesar del cálculo de entropía. Así que es casi imposible verificar la lista (desconocida) de antemano. Sin embargo, al intentarlo, unos 65 millones de palabras, no daña, consulte Contraseñas de ID de SUNet de Stanford . 65M es mucho, pero esta lista contiene casi 2.5 mil millones de contraseñas: Contraseñas de MySQL

Un proceso de generación de PW de alta entropía y una herramienta que compruebe dicha entropía, deben complementarse con un paso de rechazo que utiliza listas y patrones. Incluso esos procesos de alta entropía pueden generar contraseñas fáciles de adivinar, como aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa (ver más abajo), y password1 .

Le he preguntado al cracker de los hashes de Ashley Madison cómo podrían descifrar las frases de contraseña largas que publicaron. Solo una respuesta genérica, pero después de analizar las publicadas, descubrí que la mayoría de esas frases largas son expresiones comunes o etiquetas hash, consulte fuente de algunas frases AM agrietadas

La única excepción a las listas como fuentes, son las contraseñas que tienen un patrón como: capital, luego minúscula seguido de un número. Los patrones comunes, con% de éxito, están disponibles en Internet. Esos podrían ser fácilmente comprobados de antemano.

- edición ajustada 2.5 billones; Parte 'aaaaaaa' agregada; rechazo reformulado

Una palabra: Política

Durante la última década, la tendencia principal en la seguridad de la información es hacia el cumplimiento, el control y las políticas. Básicamente, lo que hacemos hoy es crear un SGSI (Sistema de gestión de seguridad de la información) basado en el compromiso de nivel C y las políticas corporativas.

Y cuando llegas a escribir la política de contraseña, no estás en el nivel técnico. Está escribiendo un documento que los empleados necesitan leer, entender y posiblemente firmar. Usted está escribiendo un documento que la administración debe aceptar y respaldar. No puedes profundizar demasiado en las matemáticas, o no obtendrás aceptación.

Finalmente, cuando piensa en cómo implementar realmente la política de contraseña, en casi todas las organizaciones no es libre de inventar sus propias reglas. Tendrá algo como ejecutar Active Directory y su implementación tiene que trabajar con él, o el sistema IDM, la pila heredada o lo que sea.

Entonces, con lágrimas en los ojos, escribimos políticas de contraseña que sabemos que son medio estúpidas, porque es lo mejor que podemos hacer.