¿Puede un atacante extrapolar códigos futuros basándose en códigos pasados y sus marcas de tiempo de un dispositivo TOTP?

1

Recientemente comencé a usar un mando TOTP para proteger algunas de mis cuentas de alojamiento en la nube, y es probable que me familiarice con los posibles vectores de ataque que debería vigilar mientras uso este sistema (mi experiencia anterior es con U2F / YubiKeys , y no TOTP, y soy consciente de que TOTP tiene un principio de funcionamiento bastante diferente al de U2F).

Cuando registré mi fob con mi proveedor en la nube, me pidieron el número de serie del hardware del fob, así como dos códigos consecutivos.

Mi pregunta es la siguiente: dado que solo un número (no necesariamente 2) de códigos caducados pero con marcas de tiempo, ¿podría un atacante adivinar códigos futuros?

¿Y si el atacante también tuviera el número de serie del hardware del mando a distancia?

¿O los dos vectores de ataque son poco realistas (es decir, el fob simplemente produce códigos difíciles de adivinar pero fáciles de verificar)?

    
pregunta Jules 07.06.2016 - 00:50
fuente

1 respuesta

4

Depende de la implementación del token. Hay 3 tipos de implementaciones, y solo la primera es "vulnerable":

1: Algunos tokens se entregan donde la semilla se puede calcular a partir de la serie del hardware de una manera determinada. Esto puede suceder si ordena un token donde puede "usarlo con su propio servidor sin necesidad de API" o algo similar a eso, algo como un "token TOTP universal" o "token HOTP universal". Luego se supone que debes quitar la etiqueta con la serie después de haber recibido el token, y generalmente la serie será más difícil de adivinar.

En este caso, alguien con el conocimiento de la serie podrá calcular códigos futuros.

2: ha pedido el token del servicio en la nube en cuestión: Entonces no hay problema, ya que cuando se fabrica su token, se crea un archivo con sus números de serie y semillas secretas, y se envía a su proveedor de la nube. (Algunos modelos de token incluso permiten que el proveedor de la nube "reinicialice" el token con su propia semilla) Luego, su proveedor de nube crea una base de datos a partir de este archivo.

Cuando ingresas a la serie en el sitio del proveedor de la nube, solo buscan la semilla para ese token en particular y almacenan esa semilla dentro de tu cuenta.

3: se usa un sistema de token con una API, donde se solicita el token de un "proveedor de token" que también proporciona una API de autenticación para que lo utilicen los servicios de confianza de terceros:

Otros sistemas de token, como Symantec VIP, dependen de una API, donde solo se registra el hardware en serie con el proveedor de la nube, solo el número de serie se almacena dentro de la cuenta. Cuando se produce una autenticación, el proveedor de la nube enviará una solicitud al Servidor de Symantec, preguntando si el código "xxxxxx" es un código correcto para el token serial "xxxxxxxxxxxx". Esta es la razón por la que un compromiso no puede ocurrir incluso si el mismo token se registra en múltiples servicios.

Y por qué se le solicita que proporcione 2 códigos de subsuente al registrar el token:

El motivo por el que se le solicita que proporcione 2 códigos de subsuencia, es para garantizar que el token sea utilizable, de modo que no se quede fuera de la cuenta de forma accidental. Este proceso también funciona como un proceso de resincronización, donde el servicio encontrará la "sincronización inicial" del token, al buscar esa ventana en particular donde existen estos 2 códigos, y la búsqueda podría realizarse como tousands de códigos para garantizar que incluso un El token se puede registrar con el servicio. Si solo se proporciona un código, existe la posibilidad de que el código en particular exista en algún otro lugar, ya que es probable que se repitan 6 u 8 dígitos, y el servidor podría establecer accidentalmente un valor de sincronización inicial incorrecto para su token, dejándolo bloqueado.

Cuando realiza un proceso de resincronización, que puede ser iniciado por el administrador / servicio de asistencia, o puede ser un proceso automático que se inicia mediante una serie de códigos no válidos, también se le solicita que proporcione 2 códigos de subsistencia. Esta vez, no es para evitar una resincronización no válida ya que es muy desagradable, pero para aumentar la seguridad, ya que el servidor generalmente buscará alrededor de 50-100 códigos hacia adelante, y también 50-100 códigos hacia atrás (configurables), lo que haría más agradable que un atacante podría adivinar el código si solo se usara uno, pero, por supuesto, el servidor nunca retrocederá más allá del último código utilizado, ya que esto permitiría la reutilización de los códigos de token.

Sin embargo, la conclusión es que no debería compartir los seriales de token de todos modos, porque a veces, el token de serie puede ser datos de autenticación parciales para la recuperación de la cuenta, por lo que con el uso de token de serie, un atacante podría convencer al servicio de asistencia. personell para desactivar 2FA para su cuenta con como "Mi token se ha vuelto negro, algo anda mal con eso" y demás, y el personal del servicio de asistencia solo está tratando de ayudar, y se está enamorando del truco de la ingeniería social.

    
respondido por el sebastian nielsen 07.06.2016 - 08:14
fuente

Lea otras preguntas en las etiquetas