¿Cómo se realiza la resincronización para las claves de seguridad / dispositivos MFA?

1

Cuando una clave de seguridad del dispositivo MFA (basada en el tiempo) se desvía de la sincronización, hay un procedimiento para volver a sincronizarla. Pero no hay entrada para el dispositivo en sí.

Las aplicaciones para teléfonos inteligentes no tienen este problema. Supongo que esto se debe a que la aplicación tiene acceso al reloj exacto de los proveedores de telecomunicaciones. Los dispositivos clave de seguridad deben tener su propio reloj o fuente de tiempo, que puede ser atacado (recibirlo a través de una señal de radio como WWV o CHU en América del Norte), o deriva (reloj interno). Estoy adivinando que todos los dispositivos que he visto usan un reloj interno, porque a menudo hay muchos informes de que necesitan ser resincronizados. Pero no es obvio cómo esto se hace tan rápido o en lugares sin fuentes de reloj. Tampoco es obvio por qué se necesita una configuración administrativa para volver a sincronizar el dispositivo.

¿Puede alguien explicar (o proporcionar un buen enlace que explique) cómo se vuelve a sincronizar el dispositivo? Quiero comprender el grado de riesgo que esto podría tener.

    
pregunta Skaperen 14.11.2017 - 07:46
fuente

1 respuesta

1

Para los tokens basados en el tiempo hay básicamente dos métodos.

Primero que todo, ya que la hora en un token no se puede manipular (es un frob aislado con mal reloj o está alojado en un sistema donde no puedes influir en el reloj).

Entonces, lo que se debe hacer es en el servidor de autenticación, usted mantiene una diferencia de tiempo estimada (o un modelo de compensación más complejo) y lo ajusta en cada inicio de sesión.

Básicamente, se compara la entrada de la autenticación actual con unos pocos códigos antes y después del código actual. Si coincide, sabes un desplazamiento para aplicar la próxima vez.

Este método de corrección puede ser tan complicado como quieras, ya que no quieres permitir que un atacante influya en tus estimaciones o no quieres hacer la ventana demasiado grande, ya que permite más adivinanzas. (Por ejemplo, mantenga un historial de las últimas 3 autenticaciones y compensaciones y realice una regresión lineal para encontrar no solo el desplazamiento sino también la pendiente de la diferencia)

Si decide que la desviación del tiempo es demasiado grande (o no tiene datos iniciales para la predicción), solicite varias entradas. Esto reducirá el riesgo de aceptar un código de repetición (en un período de tiempo demasiado amplio).

Para el registro inicial, es probable que desee permitir un intervalo de tiempo más amplio antes de rechazar un token (sin embargo, tenga cuidado si el token tiene un reloj roto y acepta el registro; podría correr el riesgo de que falle un inicio de sesión futuro, lo que es más molesto que rechazar un registro de dispositivo)

El mismo mecanismo se aplica exactamente a los sistemas basados en contadores (con la tarea adicional para dar cuenta de las actualizaciones perdidas del temporizador y, por suerte, nunca de compensaciones negativas)

    
respondido por el eckes 14.11.2017 - 10:44
fuente

Lea otras preguntas en las etiquetas