El "OT" en "HOTP" significa "una sola vez". Esto es cierto solo si el servidor efectivamente rechaza las contraseñas correspondientes a un valor de contador que no es mayor que el último valor confirmado. Tener "un poco de margen" aquí significaría aceptar que una contraseña dada se acepte dos veces, lo mismo que HOTP intenta evitar .
Todo esto se basa en la idea de que el propietario de HOTP usa sus contraseñas de manera secuencial; nunca hay una situación en la que el propietario tenga algún interés en usar una contraseña que no sea la última que produjo su dispositivo generador de contraseña. En consecuencia, si el servidor recibió en algún momento la contraseña correspondiente al valor de contador 1567, entonces el servidor sabe que el dispositivo del propietario ha pasado al valor 1568, y cualquier intento de usar, por ejemplo, la contraseña 1565 sería una indicación segura de juego sucio.
La "ventana" es hacia el futuro, porque el propietario del dispositivo puede haber presionado el botón inadvertidamente unas cuantas veces sin notarlo, por lo que quizás la próxima contraseña corresponda al valor de contador 1575, no a 1568, y el servidor aún aceptalo.
En otras palabras, el comportamiento de la ventana como se especifica en RFC 4226 es el margen que necesita. No debe haber necesidad de ningún margen en la otra dirección; Si existe tal necesidad, es probable que esté haciendo un mal uso incorrecto de HOTP.
Editar: si tiene varios servidores que consumen contraseñas de un solo origen de la misma fuente, entonces espero que dirija todas esas contraseñas a un único servidor de autenticación, que mantenga el valor del contador. (Si este no es el caso, entonces tienes problemas mucho más grandes).
Si simplemente teme que dos OTP de este tipo puedan llegar al servidor de autenticación "fuera de servicio", puede hacer que las cosas sean un poco más flexibles sin comprometer la seguridad, pero requiere cierto cuidado. La propiedad importante de un sistema de contraseñas de una sola vez es que cada valor de contraseña debe usarse una vez. El valor del contador, con la semántica explicada en RFC 4226, es una forma económica y eficiente de mantener esta semántica: el servidor solo tiene que recordar el último contador visto, y eso es todo.
Sin embargo, puede hacer que el servidor de autenticación recuerde los valores de contraseña realmente utilizados. Esto puede ser una "ventana hacia atrás": en cualquier momento, el servidor tiene un contador actual N , que es el valor más alto del contador visto, y recuerda todos ven las contraseñas en el Rango de N-9 a N . Con una ventana de este tipo, el servidor puede recibir contraseñas ligeramente fuera de orden: se aceptará una contraseña si su contador M es mayor que N , o está en el N-9 a N y aún no se ha visto. La programación en el servidor es un poco más compleja, pero no insuperable.
Nota importante: la "ventana hacia atrás" es segura en el caso de HOTP, pero eso no se extiende a cualquier esquema de "contraseña única". Esto es seguro para HOTP porque HOTP es un MAC calculado sobre un valor de contador: depende del contador para no repetirse , pero no en los posibles valores de contador utilizados en orden numérico. Lo mismo no sería cierto para los esquemas de contraseña de un solo uso que usan cadenas de hash (donde cada OTP es un hash del siguiente uno). Lo que digo aquí es solo para HOTP.