Sí, funciona como dices. El chip es "a prueba de manipulaciones" y borrará la "semilla" (clave secreta) si se intenta atacarlo. Esto se logra a menudo teniendo una batería no reemplazable por el usuario y una "trampa" que interrumpe la alimentación del dispositivo una vez que se abre el dispositivo o se retira la superficie del chip. Luego, la clave se almacena en una SRAM, que requiere energía para mantener la clave.
La clave es una semilla, que combinada con la hora actual en el paso de 60 segundos (efectivamente, la marca de tiempo actual de UNIX / 60), actualiza el código.
No, el dispositivo NO necesita ser preciso. En su lugar, el servidor almacenará la hora del último código aceptado. Luego, el servidor aceptará un código un minuto antes, un minuto antes y en el momento actual, de modo que si la hora actual en el servidor es 23:20, entonces aceptará un código de 23:19, 23:20 y 23: 21.
Después de esto, almacenará la hora del último código aceptado, por ejemplo, si se aceptó un código 23:21, almacenará 23:21 en una base de datos, y se negará a aceptar cualquier código generado a las 23:21 o antes.
Ahora a la parte interesante: para evitar que un token impreciso se desincronice del servidor, el servidor almacenará en su base de datos, si se le exigió que acepte un código 23:19 o un código 23:21 a las 23:20 . Esto asegurará que en el próximo inicio de sesión, el servidor corregirá el código con el número de pasos.
Digamos que en el reloj 23:20 inicia sesión con un código 23:19. El servidor almacena "-1" en su base de datos (y si fuera un código 23:21, almacenaría "+1" en la base de datos). La próxima vez que inicie sesión, el reloj es 23:40. Entonces el servidor aceptará un código 23:38, 23:39 o 23:40.
Si se acepta un código 23:38, almacenará "-2" en la base de datos, a las 23:39 mantendrá "-1" en la base de datos, y a las 23:40 almacenará "0" en la base de datos.
Esto asegura efectivamente mantener el servidor sincronizado con su token. Además de esto, el sistema, si un token "corría demasiado lejos" del servidor (debido a que no se usó durante mucho tiempo), permite la resincronización. Esto se logra ya sea por un administrador del sistema, o se presenta un servicio de resincronización de autoservicio donde se le pide al usuario del token que proporcione 2 códigos subsiguientes del token, como 23:20 y 23:21, o 19:10 y 19:11. Tenga en cuenta que el servidor NUNCA aceptará un código de token generado en o antes de la fecha en que se usó el "último código de token usado" (ya que esto permitiría la reutilización de los códigos OTP). Cuando se realiza una resincronización, el token almacenará la diferencia de los 2 códigos de token proporcionados, y la hora actual del servidor y en una resincronización, la ventana de búsqueda podría ser de más / menos 50 pasos (lo que permitiría aproximadamente 0,75 horas de Desincronización en ambas direcciones).
El servidor puede detectar un token desincronizado generando los 50 códigos anteriores y los 50 códigos futuros, y si el código especificado coincide con eso, iniciará el proceso de resincronización automáticamente. Muchas veces, para evitar que un atacante use el proceso de resincronización para encontrar códigos válidos, una vez que una cuenta está en modo de resincronización, no se aceptará el inicio de sesión sin volver a sincronizar, lo que requeriría que el atacante encuentre el código exacto o posterior al código. encontrado.
