Confundido sobre el uso de una contraseña que "llevaría siglos para romper"

Las calculadoras en línea están basando sus resultados en un conjunto particular de suposiciones, que pueden no aplicarse en ningún caso. No hay ninguna base para confiar en que las calculadoras proporcionen información sobre cómo un atacante podría elegir romper la contraseña.

Por ejemplo, si sé que usas un patrón y cuál es ese patrón, entonces ajustaré mi fuerza bruta para alinearme con el patrón. No hay forma de que una calculadora en línea lo tenga en cuenta. Hay otros factores similares a tener en cuenta. "Entropía" tiene que ver con garantizar la mayor aleatoriedad posible. Un patrón establecido tiene una aleatoriedad muy reducida, independientemente de los caracteres utilizados.

Entonces, sí, prohíbe tales patrones obvios, si eso cumple con su objetivo.

Sin embargo, me preocupa su método para prohibir estas contraseñas. Podrías estar luchando la batalla equivocada.

  

Solo por curiosidad, lo verifiqué en un sitio web muy conocido (en su página de inicio de sesión) y dije que tomaría siglos romperlo.

Tales sitios web no pueden ser tomados como evangelio. Muchos no valen nada, e incluso para los buenos, los resultados deben interpretarse cuidadosamente. En primer lugar, como regla general, un comprobador de fuerza puede decirle de manera concluyente que una contraseña es débil pero que realmente no puede demostrarle que una contraseña es fuerte; la contraseña en la que no puede encontrar errores podría caer en algún ataque que el medidor no modela Para algunos ejemplos extremos, este artículo de Ars Technica describe ataques de cracking exitosos en algunas frases de contraseña por lo demás impresionantes :

  

Casi inmediatamente, una avalancha de contraseñas que antes eran difíciles de revelar se reveló. Incluían: "¿Alguna vez volveré a ver tu cara?" (36 caracteres), "al principio era la palabra" (29 caracteres), "de la génesis a las revelaciones" (26), "No puedo recordar nada" (24), "thereisnofatebutwhatwemake" (26), "givemelibertyorgivemedeath" (26 ), y "al este del este al oeste de la luna" (25).

La otra cosa es que solo porque un medidor le haya dicho que juzga que la contraseña es segura no significa que todos los medidores lo hagan. Por ejemplo, el corrector zxcvbn , que es uno de los mejores, piensa que esto se puede romper en 3 horas con un ataque fuera de línea si el el hashing de contraseña es débil:

password:              23##24$$25%%26
guesses_log10:         14
score:                 4 / 4
function runtime (ms): 3
guess times:
100 / hour:            centuries  (throttled online attack)
10  / second:          centuries  (unthrottled online attack)
10k / second:          centuries  (offline attack, slow hash, many cores)
10B / second:          3 hours    (offline attack, fast hash, many cores)

match sequence:
'23##24$$25%%26'
pattern:               bruteforce
guesses_log10:         14

Calcula 2 minutos para 1!2@3#4$5%6^ , 2@3#4$5%6^7& y a!b@c#d$e%f^ con un ataque de 10B / segundo (3 años a 10k / segundo), por lo que los que cree son aún peores. (Aunque los puntúa todos 4/4. El medidor recomienda que realmente aceptes cualquiera de estas contraseñas, porque estima que es bastante probable que resistan los ataques si tu aplicación ha implementado el hashing de contraseñas lento . Pero su análisis en realidad prueba que son débiles ante un ataque específico que debe mitigar.)

Tenga en cuenta que zxcvbn modela ataques basados únicamente en el conocimiento general de cómo la mayoría de los usuarios eligen las contraseñas; no tiene ningún conocimiento específico sobre cómo las políticas o prácticas de contraseña de su organización podrían permitir un ataque especializado a alguien que las aprende. Y siempre recuerde, la herramienta puede decirle que una contraseña es débil, pero no que sea fuerte; zxcvbn estima siglos para descifrar Am i ever gonna see your face again? , que del artículo Ars que sabemos ha sido descifrado la vida real.

  

Ahora, estoy confundido con la lista, ¿debo marcar estos tipos particulares de contraseñas como vulnerables y no permitir que los usuarios los busquen, incluso si tardan mucho tiempo en romperse?

Tu instinto de que estas contraseñas deben ser prohibidas en realidad resulta tener alguna justificación, como lo muestran los resultados de zxcvbn. El problema es que es poco probable que logres compilar una lista finita de contraseñas que son igualmente vulnerables, ni de patrones que un atacante pueda explotar con éxito. Por ejemplo, para capturar todas las contraseñas que zxcvbn cree que son tan vulnerables como las tres últimas, necesitaría una lista con 1.2 billones de entradas (10B contraseñas / segundo × 2 minutos). No practico. Incluso si intentas condensar las cosas en una pequeña lista de patrones para rechazar, no contaría con que los atacantes pensaran con éxito.

Una cosa que definitivamente debes hacer es usar hashing de contraseña fuerte, con las funciones de hash de contraseña bcrypt o Argon2. Esto es lo que los resultados de zxcvbn anteriores llaman "hash lento" y probablemente hace que las entradas de contraseña sean mucho más difíciles de romper. (Pero una vez más, recuerde que un comprobador de fuerza puede decirle que alguna contraseña es definitivamente insegura, pero no que sea segura).

Cosas que debes considerar además:

• Use una pequeña lista (miles) de contraseñas que se sabe que son muy comunes, y prohíba esas. Estas listas se pueden encontrar fácilmente en línea.
• Use 500M + lista de contraseñas violadas de Troy Hunt , que también tiene una API en línea. (Asegúrate de leer el material sobre k-anonymity para que realmente no enviar contraseñas a la API!)
• Use una biblioteca de medidores de fuerza inteligente como zxcvbn, que es una alternativa mucho más sofisticada para la detección de patrones como lo que está contemplando.
• Implemente un segundo factor de autenticación, de modo que las contraseñas no sean su única línea de defensa.

La posibilidad de adivinar las contraseñas significa saber algo sobre el tipo de contraseñas que las personas pueden elegir. Todos sabemos que "Contraseña" es adivinable porque es una palabra en inglés. Pero para saber que necesita saber inglés o tener una idea de cómo el inglés u otros idiomas relacionados deletrean palabras. Un extranjero de algún lugar cercano a Betelgeuse que nunca haya estado expuesto al inglés u otro idioma humano no sabrá que la "Contraseña" es fácil de adivinar. En otras palabras, los patrones son algo subjetivos, lo que (más allá de cierto nivel) los hace terriblemente difíciles de predecir por adelantado.

De manera similar, para algunas de las contraseñas en su lista no es inmediatamente evidente cuál es el patrón. 1! 2 @ 3 # 4 $ 5% 6 ^ parece algo "aleatorio" a primera vista, pero rápidamente notará que en un teclado QWERTY, es simplemente 1-6, y alterna todos los demás caracteres con la tecla shift.

Además, si alguien le mostró la contraseña CPE1704TKS, también podría pensar que es una buena contraseña. Tiene 10 caracteres de letras y números, no tiene un patrón repetible determinable y no es una palabra en ningún idioma humano. Sin embargo, estarías equivocado, y esta no es una gran contraseña porque es la contraseña utilizada para lanzar los misiles nucleares al final de la película Wargames.

Por esta razón, el uso de cálculos de "crackability" (basados en la selección de caracteres y longitudes) de un sitio web aleatorio es en gran medida falso. Además, dependen de que alguien obtenga los hashes de contraseña, lo que en sí es un importante compromiso de seguridad. Son doblemente falsos porque implican que sabes lo rápido que toma un hash. Las velocidades de hash varían en muchos órdenes de magnitud según el algoritmo que hayas elegido. Así que tome las puntuaciones de "agrietamiento" con un grano de sal. La mayoría de los ataques a las contraseñas en estos días usan contraseñas comunes, o contraseñas reutilizadas no hash de contraseñas robadas.

Realmente, todo se reduce a mantener una lista de "contraseñas malas" que otras personas han encontrado a lo largo de los años y que tienen algún significado especial. Supongo que de ahí es de donde vienen los chicos de seguridad.

Es imposible probar que una contraseña dada es difícil de descifrar.

Lo que quiere decir con la afirmación (correcta) de que estos "son altamente vulnerables" es que existe un algoritmo más fácil de adivinar para generarlos, a saber, "golpear la fila del número de un teclado QWERTY en tal y tal patrón simple". Resulta que este algoritmo es fácil de reconocer para un ser humano que pasa todo el día presionando los dedos en un teclado así, pero los patrones en ese teclado son en realidad bastante "no obvios para una computadora", porque de hecho la mayoría de los programas de computadora no lo hacen. No importa en absoluto la distribución física de las teclas ^† .

Igualmente, podría dar un ejemplo como YWJjZGVmZ2hpamts , que podría pensar que es una contraseña bastante segura, pero en realidad estaría equivocado porque es la codificación Base64 de la cadena abcdefghijkl , y eso podría parecer totalmente obvio a una AI para la cual una cadena es principalmente un patrón de bits.

La noción de cuán simple puede expresarse un bit de información dado se llama complejidad de Kolmogorov . A pesar de la definición simple, este es realmente un concepto muy complicado: depende en gran medida del lenguaje en el que desea expresar todo, y es indiscutible . Realmente lo mejor que podría hacer es evaluar todos los programas cortos posibles en un lenguaje de programación expresivo con una gran biblioteca estándar, pero si eso no tiene éxito, no garantiza de ninguna manera que no haya La forma de la entropía para calcular la contraseña en otro idioma que incluye una función estándar crucial. Si no conocía el diseño de QWERTY, también podría pensar que asdfqwerzxcv es seguro, a pesar de la completa evidencia cuando lo sepa.

El resultado final: si encuentra alguna representación de baja entropía de una contraseña dada, entonces sí, prohíbala. Pero nunca tome la aseveración de nadie (incluyendo cualquier programa ) a un valor nominal de que una contraseña dada es segura si no saben cómo se generó la contraseña. Si desea garantizar contraseñas realmente ilegibles, la única forma es asegurarse de que salgan de un proceso aleatorio físico cuántico-mecánico.

^† _{Sin embargo, cualquier programa relacionado con el descifrado de contraseñas debería conocer los diseños de teclado, porque es bien sabido que los humanos tienden a recurrir a tales patrones. Además, 23##24$$25%%26 es bastante fácil, incluso sin conocer la distribución del teclado, porque la fila de números está casi ordenada en ASCII. Por lo tanto, estos sitios web realmente están haciendo un trabajo terrible aquí.}

^‡ _{Eso es incluso ignorar los problemas de tiempo de ejecución. Lo que estás haciendo aquí es tan difícil como forzar una contraseña desconocida .}

Una contraseña como "12345678" podría considerarse aleatoria, si lo desea. Si utiliza un generador de contraseñas aleatorias, la probabilidad de generar "12345678" es la misma que la de "4h2Ud8yG" (solo se consideran las contraseñas alfanuméricas). Y "12345678" puede ser tan difícil de romper como "4h2Ud8yG", si lo fuerza bruscamente en el rango de "00000000" a "ZZZZZZZZZ". Pero la verdad es que las contraseñas no solo deben ser aleatorias, también deben verse al azar. ¿Por qué? Debido a que los atacantes a menudo usan bruteforce en base a diccionarios o patrones, las contraseñas que no están basadas en palabras o patrones son más seguras. Además, si se usan palabras y patrones para hacer que la contraseña sea más fácil de recordar, entonces es probable que todas las otras contraseñas utilizadas por la misma persona sean más fáciles de recordar de la misma manera. Entonces, si un atacante roba una de sus contraseñas y se parece a "John75", es probable que rompan la mayoría de sus contraseñas con patrones de fuerza bruta como "nombre + número", "palabra + número" o algunas variaciones. Pero si el atacante roba una de tu contraseña y se ve aleatoriamente como "4h2Ud8yG", entonces no podrán extraer ninguna información de ella.

Así que tienes razón cuando dices que las contraseñas que tienes no son realmente seguras. ¡Ni siquiera tienen toda la entropía que crees que tienen! Y esto se debe a que la entropía de la contraseña se basa en la apariencia de una contraseña o en la forma en que se crea una contraseña. Una contraseña como "1! 2 @ 3 # 4 $ 5% 6 ^", si lo piensa como "número seguido de un símbolo, seis veces", tendría (10x10) ^ 6 = 10 ^ 12 posibilidades. Lo que es menos que las posibilidades de una contraseña simple de 8 caracteres hecha de letras minúsculas y números: 36 ^ 8 = 2.8 x 10 ^ 12 posibilidades. Pero si piensa en esa contraseña de ejemplo como "número seguido de un símbolo en la misma tecla, comenzando desde 1 en orden ascendente, seis veces", entonces las posibilidades totales son ... ¡solo una!

Primero que nada, esos indicadores de contraseña estricta son pautas, no verdad absoluta.

En segundo lugar, la seguridad de una contraseña o el tiempo de descifrado dependen de algunos factores. Para entender mejor esto, es importante entender cómo se "rompen" las contraseñas en primer lugar.

Hay 3 ataques comunes a las contraseñas:

1. Los atacantes intentan iniciar sesión en un servicio adivinando la contraseña
2. Los atacantes encontraron la misma combinación de nombre de usuario / contraseña en una infracción por separado y ahora la están usando en contra de un servicio no saturado (relleno de credenciales)
3. Los atacantes obtuvieron el volcado de base de datos de un servicio y tienen el hash de contraseña. Ahora están forzados a usar el hash para determinar la contraseña de texto simple.

Para evitar que los atacantes adivinen las contraseñas, aplicamos algún tipo de 'regla de entropía' Y que intentamos el inicio de sesión con límite de velocidad. De esta manera, los atacantes no pueden forzar tu servicio directamente.

Prevenir el relleno de credenciales es más difícil. Independientemente de cuán fuertes sean las contraseñas, será de poca ayuda si el usuario tuviera la misma contraseña en un sistema violado por separado, y ese sistema la almacenó en texto simple. !

Algunas empresas (especialmente Amazon, LinkedIn y OpenTable) incluso están accediendo a las violaciones de datos y alertando a sus clientes - a pesar de que esas brechas están fuera de dichas compañías . Esto ayuda a proteger contra el relleno de credenciales (¡un poco!), Pero puede ser un poco demasiado lejos.

Por último, está el típico bloqueo de contraseña para un hash de contraseña. Aquí es donde un atacante de alguna manera se ha apoderado de los hashes de contraseña de los usuarios y ahora está tratando de adivinar el texto sin formato de los hashes. Aquí es donde comúnmente escuchamos el tardará siglos en romper trope.

Normalmente, el atacante usará una herramienta como ocl-hashcat en combinación con una lista de palabras de contraseña común (como las contraseñas de RockYou o Top1000, etc.) para adivinar el texto sin formato. Los atacantes también pueden aplicar fuerza bruta a todas las combinaciones de letras, números y caracteres especiales, pero esto no es común, ya que es menos eficiente que una lista de palabras.

La ralentización del ataque, usualmente confiamos en:

• Uso de una función de hash fuerte (Bcrypt en lugar de MD5)
• Contratar contraseñas individuales (para forzar a los atacantes a fuerza bruta una por una)
• Evitar que los usuarios usen contraseñas débiles
• Impedir que los usuarios usen contraseñas en violaciones de datos anteriores (porque la lista de palabras está formada por contraseñas que ya no se cumplieron).

Para los últimos 2, NIST recomienda lo siguiente:

Al procesar solicitudes para establecer y cambiar secretos memorizados, los verificadores DEBEN comparar los posibles secretos con una lista que contenga valores que se sabe que son utilizados, esperados o comprometidos. Por ejemplo, la lista PUEDE incluir, pero no se limita a:

• Contraseñas obtenidas de corpuses de infracciones anteriores.
• palabras del diccionario.
• Caracteres repetitivos o secuenciales (por ejemplo, "aaaaaa", "1234abcd").
• Palabras específicas del contexto, como el nombre del servicio, el nombre de usuario y sus derivados.

Obviamente, los servicios deben forzar el restablecimiento de la contraseña una vez que se descubre una infracción en su servicio.

En resumen, no se confunda acerca de tomar siglos para romper el disparate. Aplique un conjunto razonable de prácticas relacionadas con la protección de contraseñas y debe ser bueno, no confíe totalmente en estos indicadores de seguridad de la contraseña para determinar su postura de seguridad. Este enlace NIST es un buen lugar para comenzar.

La mayoría de los consejos en línea sobre contraseñas es, por decirlo así, sin ningún fundamento sólido. Esto se aplica especialmente a la llamada complejidad de las contraseñas, que se basa en un mito de los años 80 y, afortunadamente, después de que el autor original de NIST lo admitiera el año pasado, ya no está disponible.

Usted puede no hacer una estimación de la fortaleza de la contraseña sin entender lo que realmente son las amenazas. Todas las calculadoras triviales en línea no tienen sentido, ya que solo hacen algunos cálculos matemáticos sin tener en cuenta lo que intentas proteger contra .

Su amenaza podría ser fuerza bruta . En tal caso, lo primero que debe hacer es no permitir ataques de fuerza bruta. Si alguien ingresa una contraseña incorrecta cien veces y no lo está bloqueando, está haciendo algo incorrecto que no tiene nada que ver con la seguridad de la contraseña. La segunda cosa que hacer es longitud > complejidad (ponlo en Google, gran artículo).

Si su amenaza es un ataque de diccionario a sus hashes de contraseña, lo primero que debe hacer es proteger sus hashes correctamente. El segundo es saltear y hacer hash correctamente con una función hash adecuada (bcrypt, scrypt, etc., no MD5 o SHA1). El tercero es no permitir palabras simples del diccionario y permutaciones. Use la misma lógica que usan los crackers, algunos de ellos están disponibles públicamente.

Si su amenaza es el uso de etiquetas adhesivas o etiquetas adhesivas post-it, usted quiere evitar la aplicación de la complejidad sin sentido, y asegurarse de que sus usuarios realmente puedan recordar sus contraseñas y escribirlas rápidamente. De nuevo, la longitud > complejidad. Haz la longitud mínima de 12 caracteres, pero permite palabras compuestas.

Y así sucesivamente ...

En resumen: considere sus amenazas, no confíe en cálculos matemáticos triviales.

  

Solo por curiosidad, lo verifiqué en un sitio web muy conocido (en su página de inicio de sesión), y declaró que tomaría siglos romperlo.

Tales afirmaciones son siempre muy dudosas.

El problema fundamental es que para calcular cuánto tiempo le tomaría a un atacante romper una contraseña, se necesita un modelo del atacante.

Un atacante idealizado intentaría contraseñas en orden de lo más probable a lo menos probable. Por supuesto, un verdadero atacante no sabe qué tan probable es una contraseña dada, por lo que tienen que adivinar, por lo general, combinarán algún tipo de diccionario (que si el atacante es algo competente contendrá mucho más que solo palabras comunes en inglés) con una montón de reglas de generación.

El problema es que los modelos de atacantes utilizados por los medidores de seguridad de contraseñas a menudo están muy por detrás de los atacantes reales en cuanto al tamaño de sus diccionarios y la complejidad de sus reglas.

El problema fundamental con las restricciones de contraseña es que cualquiera que sea la restricción que haga a los usuarios, a menudo hará lo mínimo para que su contraseña sea aprobada.

Ahora esto puede agregar algo de entropía, normalmente hay más de una forma mínima de mutar una contraseña para que pase las reglas, pero la entropía agregada es mucho más pequeña de lo que sugiere un análisis ingenuo. Por ejemplo, si obliga a los usuarios a agregar un número a su contraseña, es probable que un número desproporcionado de ellos elija 1.

Es probable que esté confundido porque se supone que es posible definir la vulnerabilidad de la contraseña a priori. En cambio, depende en gran medida de qué patrón intentaría primero un atacante real. El atacante oportunista probablemente probaría primero un diccionario o listas de contraseñas filtradas. Pero al poner incluso un esfuerzo moderado, pueden ser bastante precisos. Esta es una razón por la cual es una batalla perdida para hacer cumplir las directrices sobre contraseñas. La mayoría de las pautas promueven que los usuarios sigan ciertos requisitos mínimos al elegir sus contraseñas. Esto puede ayudar a forzarlos de manera brutal . Por ejemplo,

• una longitud de contraseña mínima de X caracteres permite que un atacante evite probar todas las contraseñas más cortas que X y, en cambio, se centre en las contraseñas de longitud X, X + 1 o X + 2 suponiendo que muchos usuarios solo cumplen con el requisito de longitud mínima.

• Al imponer un patrón como "minúsculas, mayúsculas, números y caracteres especiales", un atacante puede asumir que hay usuarios que obtienen su contraseña usando exactamente este patrón .

• Sería posible darles retroalimentación si su contraseña era una contraseña filtrada, pero luego existe el riesgo de que terminen por modificarla hasta que pase. Nuevamente, esta es una sugerencia para los atacantes sobre cómo dirigir su fuerza bruta.

• La longitud máxima es bastante obvia. En el mejor de los casos, una longitud reduce el beneficio de usar administradores de contraseñas. En el peor de los casos, pueden sugerir las limitaciones tecnológicas subyacentes del sistema de inicio de sesión. Además, colocan un límite superior en el peor de los esfuerzos que un atacante tiene que gastar.

Para determinar cuán difícil es descifrar una contraseña, debes conocer su entropía, lo que obviamente estos sitios no pueden saber. Hacen su mejor conjetura y luego lo devuelven como resultado.

Para calcular correctamente la entropía de una contraseña, debes asumir que el atacante sabe tanto sobre cómo se creó la contraseña como lo hizo el creador. Si el creador siempre incluye una de las dos palabras de 10 letras, el atacante debe saber que una de esas palabras estará presente y lo que son.

A partir de esto, puede ver que su patrón es una entropía muy baja (no más de 7 bits). Pero como los sitios web no lo saben, lo califican como mucho más alto. Si quieres una buena contraseña, debes tener aleatoriedad. Cómo hacer que un usuario acepte e incluya aleatoriedad en la contraseña es un problema. Es mejor tratar de averiguar cómo conseguir que otra persona haga la contraseña o su contraseña equivalente.