¿Es segura la corrección automática de errores tipográficos en las contraseñas?

Revelación completa: soy uno de los autores del artículo.

Un sistema exacto de comprobación de contraseñas almacena un estándar salado, hash de compilación lento de la contraseña. Cuando una contraseña, como password123, está registrado con el servicio de autenticación, un salt aleatorio Se selecciona "sa" (esto debería ser 16 o más bytes aleatorios) y una se aplica la función hash H de ralentización para calcular: H (sa, contraseña123). El resultado, llámalo h, se almacena en una base de datos junto con la sal sa. Como se mencionó, uno debe elegir H para ser lento (10s o 100s de milisegundos para calcular). Las buenas opciones son argon2, scrypt o PBKDF2, correctamente configuradas.

Cuando un usuario intenta iniciar sesión más tarde, si ingresan su contraseña, el hash Se recalcula y verifica contra el valor almacenado. En el ejemplo anterior, Si el usuario envía la contraseña123, entonces se vuelve a calcular (otra vez lentamente) H (sa, contraseña123) y verifica el resultado --- coincide con el anterior computar h y el inicio de sesión puede ser permitido. Cualquier desviación en la contraseña enviada de la registrada previamente. da como resultado un valor hash totalmente diferente, y el inicio de sesión falla.

Nuestra idea es simple: si la primera comprobación falla, el sistema también puede aplicar un pequeño número de funciones "correctoras" a la contraseña enviada, y luego aplicar el algoritmo hash al resultado. Por ejemplo, podríamos corregir una función de corrector de bloqueo de mayúsculas F_caps que toma como entrada una contraseña y genera la contraseña con el uso de mayúsculas en todas las letras cambiadas: F_caps (PASSWORD123) = password123 y F_caps (pAsSwOrD123) = PaSsWoRd123. También podríamos arreglar un corrector de mayúsculas de primera letra: F_first (Contraseña123) = password123 y F_first (pASSWORD123) = PASSWORD123. Tenga en cuenta que estos son fáciles de implementar.

Luego, para realizar una comprobación tipográfica-tolerante, se aplicaría la siguiente lógica para una sal previamente registrada, hash pair (sa, h) y contraseña enviada pw

Si H (sa, pw) = h o H (sa, F_caps (pw)) = h o (sa, F_first (pw)) = h entonces permitir inicio de sesión

A modo de ejemplo, si uno envía PASSWORD123, las comprobaciones estarán activadas. PASSWORD123, password123 y pASSWORD123, con la segunda verificación teniendo éxito.

Algunos puntos:

1) La eficacia de los ataques de fuerza bruta fuera de línea es exactamente la misma que antes de. ¿Por qué? Porque solo almacenamos sa, h. El atacante, dado sa, h, lo hará. Sólo aprenda la contraseña a través de un ataque de fuerza bruta que intenta la correcta contraseña, en nuestro ejemplo contraseña123. No hay pérdida de seguridad aquí como No hemos cambiado cómo se calcula H.

2) Hay un cambio insignificante en la seguridad contra la adivinación remota los ataques. Lo mostramos a través de extensos análisis en el documento, pero hierve. hasta el hecho de que en el mundo real la mejor estrategia es presentar el las contraseñas más probables hasta cierto umbral (por ejemplo, muchos sitios bloquean un cuenta después de 10 intentos fallidos). Los controles extra realizados por error tipográfico. La corrección puede ayudar al atacante a tener un poco más de suerte, pero mostramos que es esencialmente despreciable. Si uno está preocupado por eso le damos Técnicas que lo reducen aún más.

3) La tolerancia tipográfica aumentará la utilización de la CPU para el servidor de inicio de sesión (y posiblemente carga de memoria, cuando H es un hash de memoria como Scrypt o argon2). Esto se debe a las invocaciones extra lentas de cómputo de H. In practicar esto no parece ser tan caro como podría esperarse (3x en nuestro ejemplo anterior) porque de todos modos los usuarios habrían terminado vuelve a enviarlo después del rechazo y pagas el precio por cada intento.

4) No sugerimos permitir errores tipográficos arbitrarios. Esto ni siquiera es posible actualmente, ya que requeriría recalcular H un número prohibitivo de veces (¡Recuerda que es lento!), y de todos modos esto sería inseguro. Uno necesita Elegir cuidadosamente qué errores tipográficos permitir en base a un análisis de principios. Nosotros Cree los dos correctores mencionados arriba, mayúsculas y primera letra. capitalización, son una obviedad para el despliegue seguro, más allá de eso empieza a tener más matices.

Agregamos una pregunta frecuente que proporciona información adicional: enlace

Editar: esta respuesta no es correcta, vea la respuesta más votada. En el apéndice se refirieron a "bocetos seguros", pero al leer el documento más de cerca, veo que no recomiendan ese método:

  

En teoría, un bosquejo seguro [17] podría usarse para corregir algunos errores tipográficos en   El lado del servidor. Sin embargo, los límites probados para construcciones existentes   son demasiado débiles para proporcionar una protección significativa para nuestro entorno (en   cuya entropía es bastante baja).

Ya reconocieron mis puntos que escribí aquí y rechazé esa idea. Me perdí completamente esa lectura del periódico la primera vez.

-

A pesar del hecho de que el documento de investigación parece altamente creíble, yo mismo no estoy de acuerdo con sus hallazgos. Aunque sus cálculos son sólidos, sus suposiciones no tienen en cuenta los escenarios de ataque del mundo real ni tienen en cuenta cómo las personas seleccionan las contraseñas.

Esencialmente, lo que están diciendo es que hay algunos errores comunes, como tener habilitado el bloqueo de mayúsculas, no poner en mayúscula la primera letra, agregar o eliminar un personaje o presionar una tecla adyacente en el teclado. Su solución propuesta permite que todos estos errores aparentemente menores sean ignorados para que el sistema acepte la contraseña lo suficientemente cerca.

Si bien esta es una gran mejora en la facilidad de uso (todos cometemos errores al ingresar contraseñas), la compensación en seguridad es mucho mayor de lo que reconocen. Parte del problema es que no se dirigen en línea (iniciando sesión en un sitio web en vivo) frente a fuera de línea (obteniendo la base de datos hash y rompiéndolas en su computadora). Con un ataque fuera de línea en el que el atacante puede potencialmente forzar miles de millones de contraseñas por segundo, las contraseñas confusas fallarían enormemente.

Digamos, por ejemplo, que un hacker obtiene una base de datos de un millón de contraseñas e intenta un ataque de diccionario híbrido contra ellas. Normalmente, el software de descifrado de contraseñas tomará una palabra como "contraseña" e intentará todas las permutaciones de eso, incluida la contraseña, pAssword, PAssword, password1, password! Etc. crackeo de contraseñas por lo que consume mucho tiempo.

En el caso de contraseñas confusas, casi todas esas permutaciones funcionarán como contraseñas válidas. Digamos que simplemente intenta "contraseña" contra todo el conjunto de un millón de contraseñas. El pirata informático obtendría coincidencias correctas para cada cuenta, palabra y cada permutación. El gran problema aquí es que muchas personas hacen que sus contraseñas sean más fuertes cambiando una letra, usando mayúsculas al azar, agregando un número o puntuación al final, etc. Las contraseñas confusas hacen que todas esas técnicas sean ineficaces.

Es importante que obligemos a un atacante a probar cada permutación para obtener incluso un milisegundo de tiempo por cada intento. Esa es precisamente la razón por la que usamos cientos o miles de rondas de hash con algoritmos como PBKDF2. Cada bit de trabajo que el software de descifrado de contraseñas tiene que ver con cada contraseña funciona a nuestro favor.

En el documento, están considerando el espacio completo de la contraseña y calculan correctamente que la comprobación difusa no reduce significativamente la cantidad de contraseñas posibles que un atacante debe atacar con fuerza bruta. El problema es que las contraseñas no se distribuyen de manera uniforme en este espacio potencial, sino que se agrupan alrededor del espacio relativamente pequeño que consiste en palabras del diccionario. Si se toma eso en consideración, la pérdida de seguridad es significativa.

Para poner esto en perspectiva, si toma la superficie de todo EE. UU. (3,8 millones de millas cuadradas) para representar todas las contraseñas posibles que se podrían elegir, las contraseñas reales que todos usen caben en un área de aproximadamente 5 pies cuadrados . Las contraseñas confusas en un espacio tan pequeño serían un desastre.

La idea funcionaría bien en sistemas con seguridad informal y donde la facilidad de uso es importante. También puede ser aceptable cuando se usa en combinación con múltiples factores de autenticación, como un token de hardware o un sensor biométrico. Pero, para todo lo demás, la técnica simplemente no es lo suficientemente segura.

Aquí hay dos posibles escenarios de ataque:

1. cracking fuera de línea
2. craqueo en línea

En la situación de craqueo fuera de línea, el documento aún describe que se deben aplicar principios criptográficos sólidos. Esto significa que no hay lógica borrosa. Solo existe el trabajo necesario para calcular el hash final sabiendo la sal y adivinar las entradas. No hay una ventaja o desventaja real de los métodos del artículo en este escenario.

En la situación de craqueo en línea, cuando el atacante está adivinando contraseñas al azar en contra de alguna fuente en línea, hay un intercambio de usabilidad y seguridad. Esencialmente, cada intento vale varios (según el algoritmo de corrección utilizado y la cantidad de corrección posible). La compensación aquí parece teóricamente mínima en un solo escenario de cuenta.

Sin embargo , dentro de un modelo de amenaza en línea realista, los ataques ocurren en una escala mucho más grande . Las botnets intentan atacar contraseñas comunes con la esperanza de que algunas sean correctas por casualidad. Lo que se describe en este documento es algo que, a gran escala, aumentaría el riesgo general de compromiso con la cuenta.

En última instancia, todo se reduce a la compensación de la usabilidad de la seguridad. En esta situación, no estaría dispuesto a establecer una política de este tipo a cualquier escala, ya que efectivamente multiplicaría la efectividad de los intentos maliciosos.

Según el documento, hay un impacto de seguridad de cero en el caso de ataques de fuerza bruta sin conexión. Esto se debe a que no hay ningún cambio en la base de datos que contiene contraseñas de hash. La comprobación en línea de errores tipográficos utiliza "comprobación exacta", es decir, la comparación con un hash almacenado, como una subrutina.