¿Las contraseñas de una sola vez se resisten a los ataques de fuerza bruta? ¿Alternativa inmune?

Tienes dos preguntas diferentes. Para responder a tu primera pregunta ...

  

¿Una contraseña de un solo uso como Google Authenticator o YubiKey protege contra ataques de fuerza bruta con un poder de computadora ilimitado?

Cuando se habla de ataques de fuerza bruta, hay que diferenciar entre ataques en línea y sin conexión.

Al considerar los ataques de fuerza bruta en línea, lo remito a la Sección 7.3 del RFC 4226.

  

Al truncar el valor HMAC-SHA-1 en un valor más corto, se convierte en bruto      fuerza de ataque posible. Por lo tanto, el servidor de autenticación necesita      Detectar y detener los ataques de fuerza bruta.

     

RECOMENDAMOS establecer un parámetro de regulación T, que define el      Número máximo de intentos posibles para la validación de contraseña única.      El servidor de validación administra contadores individuales por dispositivo HOTP en      Para tomar nota de cualquier intento fallido. RECOMENDAMOS no ser      demasiado grande, particularmente si el método de resincronización usado en el      el servidor está basado en la ventana, y el tamaño de la ventana es grande. Deberia ser      establezca lo más bajo posible, al tiempo que garantiza que la facilidad de uso no sea      impactado significativamente.

     

Otra opción sería implementar un esquema de demora para evitar una brutal      ataque de fuerza. Después de cada intento fallido A, el servidor de autenticación      esperaría un aumento de T * Un número de segundos, por ejemplo, digamos que T = 5,      luego, después de 1 intento, el servidor espera 5 segundos, en el segundo      intento fallido, espera 5 * 2 = 10 segundos, etc.

     

Los esquemas de retraso o de bloqueo DEBEN estar entre las sesiones de inicio de sesión para evitar      ataques basados en múltiples técnicas de adivinación paralelas.

Las buenas implementaciones de HOTP y TOTP, que son los algoritmos utilizados en Google Authenticator deberían limitar los intentos de inicio de sesión, lo que frena los ataques de fuerza bruta en línea.

Cuando se trata de ataques de fuerza bruta fuera de línea , el atacante debe adivinar el secreto compartido utilizado.

RFC 4226 Sección 4 tiene esto que decir sobre el secreto.

  

R6 - El algoritmo DEBE usar un fuerte secreto compartido. El largo de      El secreto compartido DEBE ser de al menos 128 bits. Este documento      RECOMIENDA una longitud secreta compartida de 160 bits.

Los ataques de fuerza bruta contra claves de esa longitud se consideran imposibles .

Pasando a tu segunda pregunta ...

  

Si no, ¿qué algoritmos son inmunes a los ataques de fuerza bruta contra datos estáticos en un HHD o USB-Stick? Considere que los datos se almacenan en un almacenamiento USB y que pierde el almacenamiento USB para el atacante que tiene una capacidad de computadora ilimitada disponible para forzar la contraseña.

Las unidades comunes no cifran su contenido de ninguna manera. Perder la unidad significa revelar todos los datos que contiene. Usted debe cifrar los datos en el disco si desea tener alguna esperanza de que permanezca seguro. Algunas unidades tienen cifrado integrado mientras que puede usar software como Truecrypt para cifrar otros.

Suponiendo que el cifrado es correcto (AES con un modo de operación adecuado y todo eso ...), se reduce a la contraseña que utiliza para derivar la clave. En esa situación, el cifrado es tan fuerte como su contraseña. Elegir una contraseña larga y aleatoria hace que sea muy improbable que un atacante pueda adivinarlo.

Esto, por supuesto, suponiendo que el atacante está limitado computacionalmente que es lo que enfrentarás en la realidad. Contra los atacantes con capacidad de computación ilimitada, necesitará una clase muy especial de algoritmos que se sabe que son información teórica segura . Algunos ejemplos de tales algoritmos son One Time Pad y Shamir's Secret Sharing.

Nada en este mundo es invulnerable a poder ilimitado de la computadora . Es bueno saber que no existe tal sistema.

1. En un escenario de ataque real, el ataque a un sistema protegido por OTP depende de la cantidad de intentos que el atacante pueda hacer en el período de tiempo del token OTP (generalmente un minuto). Si emplea una limitación de velocidad en su esquema de autenticación, empleando un retraso fijo en cada sesión de autenticación, estará bastante seguro.

2. No hay algoritmo inmune al ataque sin conexión. Hay otros muy resistentes, que tardan mucho tiempo en romperse (miles de millones de años) pero nada es inquebrantable. Si el atacante puede forzar su contraseña sin conexión con suficiente poder de cómputo, la seguridad depende de su contraseña. Cualquier dato encriptado con un algoritmo muy seguro y protegido por una clave trivial será fácilmente descifrado.

En mi respuesta, asumo que el OP habla de ataques en línea, ya que no es posible usar OTP para el cifrado sin conexión o los discos duros.

Para la primera pregunta, depende de si usa OTP basadas en el tiempo, en los eventos o en el desafío. Voy a hablar sobre el método estándar de las variantes de autenticación OTP (HOTP, TOTP, OCRA) de 6 dígitos ahora:

Basado en el tiempo: son seguros contra la fuerza bruta, ya que el atacante solo tiene 30 segundos para enumerar todos los códigos, siempre que NO tenga ninguna ventana de sincronización, y siempre que tenga sus fichas TOTP configuradas para cambiar el código cada 30 segundos. Incluso agregar una demora en 0,5 segundos en cada intento de inicio de sesión (independientemente de si tiene éxito o no), lo que básicamente es imperceptible para un usuario normal, solo le dará al atacante la capacidad de adivinar el código con una probabilidad de 1/16666, que es mucho más difícil que adivinar un pin ATM con 3 reintentos, que tiene una probabilidad de éxito de 1/3333. Después de 30 segundos, el código TOTP se cambia, lo que obliga al atacante a comenzar desde el principio nuevamente. Todavía recomendaría un captcha para evitar el ejercicio de fuerza bruta ya que el atacante podría golpear al 1/16666 por suerte.

Basado en eventos: NO son seguros contra el uso brusco, ya que se usa el mismo código estático todo el tiempo, hasta que se presenta el código correcto. La única forma de asegurar un inicio de sesión basado en eventos es bloquear la cuenta y requerir 2 códigos sucesivos para desbloquear, o usar un captcha. Una forma podría ser usar ambos. El sistema de 2 códigos sucesivos no sería notorio para el usuario final, ya que el usuario intentaría iniciar sesión en su cuenta bloqueada, simplemente obtendría "Código OTP no válido, intente nuevamente con el siguiente código". (al igual que los usuarios que realmente escribieron su OTP obtuvieron incorrectamente), el usuario naturalmente presionaría el botón nuevamente para generar el siguiente código. Después de ingresar este segundo código, a la cuenta se le habrían presentado 2 códigos HOTP sucesivos y se desbloquearía, sin que el usuario se diera cuenta de que la cuenta estaba bloqueada, y sin que un atacante se diera cuenta, ingresó el HOTP correcto (ya que la cuenta se bloquearía primero intente, por lo tanto, el atacante tendría que ingresar 2 códigos sucesivos, pero el atacante nunca podría descubrir cuándo ingresó el primer código correctamente). Requerir 2 códigos sucesivos reduciría inmediatamente al atacante a tener que adivinar algo fuera de la posibilidad de 1/1000000000000, que es equivalente a una contraseña de 6 caracteres con A-Z a-z y 0-9. Además, si el atacante ingresa el primer código con éxito pero el segundo incorrectamente, tendría que comenzar de nuevo todos esos códigos 1000000000000, ya que el primer código se invalida.

Basado en el desafío: aquí, depende del diseño. Dado que la respuesta es proporcional al desafío, aquí es importante hacer desafíos de un solo uso y que expiren. Si programa su sistema de desafío para permitir solo un desafío válido para una cuenta al mismo tiempo, asegúrese de que cada desafío sea de un solo uso (por ejemplo, el desafío se invalida en cada reintento, independientemente de la OTP correcta especificada o no), y asegúrese de que el desafío caducará cuando no se use por un tiempo, entonces el sistema será básicamente infinitamente seguro contra la fuerza bruta ya que cada intento causaría que el sistema cambie el código de acceso. Sin embargo, el atacante podría tener un 1/1000000 de suerte simplemente, como ganar el comodín con un número exacto de lotería de 6 dígitos, por lo que también debería tener captcha en dichos inicios de sesión.

El autenticador de Google, cuando se usa con Google o Facebook, es un token TOTP, por ejemplo, OTP basado en el tiempo, pero también puede cargarse con perfiles HOTP (basados en eventos).

Cuando se habla de yubikey, usar su clave interna de 44 caracteres o desactivar el identificador público que da una clave de 32 caracteres, la longitud de la clave, incluso si está basada en eventos, hace que sea prácticamente imposible forzar la fuerza bruta en un sistema protegido por yubikey , dado que la respuesta bruta de un yubikey sería igual a la clave AES de 128 bits (32 caracteres hexadecimales). Por lo tanto, independientemente de si aplica la fuerza bruta a la respuesta, o fuerza bruta de la clave de almacenamiento interna de yubikey, su trabajo será tan difícil como ambos. Un atacante querría utilizar la fuerza interna de la fuerza bruta, ya que obtendría un mayor éxito.

En tu pregunta 2, no entiendo muy bien a qué te refieres, ya que es técnicamente imposible usar OTP si el autenticador Oracle no es completamente seguro. Esto significa que el proceso o elemento que verifica las OTP debe ser confiable, y usarlas en un escenario sin conexión solo significa que el atacante podría modificar el proceso sin conexión para permitir la reutilización de las OTP antiguas y los intentos ilimitados.

1. Sí. Si se asume que la fuerza bruta sin conexión es exitosa y que han descubierto su contraseña, aún no pueden iniciar sesión en el sistema sin el token de autenticación de una sola vez. No tendrán la oportunidad de aplicar fuerza bruta al token de autenticación de una sola vez.

2. N / A debido al ' si no '