period setting does not seem to work (stuck at default) and is actually twice as long as defined
Created originally on Bitbucket by Anonymous
While trying out different implementations for a TOTP application I stumbled over a weird behaviour: The timing behaviour for the passlib library did not work as expected. I wrote a short script to directly compare passlib and pyotp. As you can see in the output below, the token was actually the same (good) and the timing verification was the same for both implementations (5s). When stepping through the time window in one second intervals, the result was quite different though:
- The pass lib result indicates that the 5s period was not used, rather the 30s default seems to have been used
- The passlib implementation uses the period symmetrically around the time reference, in effect doubling the allowed time window
I verified the results with 6 and 8 digits and ran it also on a Linux system with the same results.
(script result)-------------- version data platform info: Darwin-16.6.0-x86_64-i386-64bit python info: 3.6.0 (v3.6.0:41df79263a11, Dec 22 2016, 17:23:13) [GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] passlib version: 1.7.1 pyotp version: 2.2.6
parameters Allowed Duration (s): 5 current datetime: 2017-07-20 14:55:51.484219 current datetime in s: 1500555351 key_string: "this is a test" encoded key_string: b'ORUGS4ZANFZSAYJAORSXG5A='
passlib setup full token: passlib token-base: <passlib.totp.TOTP object at 0x103592320> verify passlib token-base duration: 5 passlib token: 977416
pyotp setup pyotp token-base: <pyotp.totp.TOTP object at 0x10358acc0> verify pyotp token-base duration: 5 pyotp token: 977416
passlib switched to true at (unix epoch, offset): 1500555320,-31 pyotp switched to true at (unix epoch, offset): 1500555350,-1 pyotp switched to true at (unix epoch, offset): 1500555355,4 passlib switched to false after true at (unix epoch, offset): 1500555385,34