I was reviewing stackoverflow for how people dealt with leftmost zeroes and I stumbled on this library
There's some issues stemming from the integer conversion where tokens with zeroes are treated as octal, and hence the implementation checks against the wrong token https://stackoverflow.com/questions/39695700/python-flask-app-leading-zeros-in-totp-error-python-2-7
But the subtle issue is that the library doesn't enforce the token length. By casting a string/int to an integer, you discard the leftmost zeroes and hence could allow 1 if the token was actually 000001.
https://github.com/tadeck/onetimepass/blob/master/onetimepass/__init__.py#L216
I suggest adhering to string semantics to avoid accepting potentially invalid input, and adopting a length constant time equality check when testing input against a candidate token here to eliminate timing side channels: https://github.com/tadeck/onetimepass/blob/master/onetimepass/__init__.py#L268
I was reviewing stackoverflow for how people dealt with leftmost zeroes and I stumbled on this library
There's some issues stemming from the integer conversion where tokens with zeroes are treated as octal, and hence the implementation checks against the wrong token https://stackoverflow.com/questions/39695700/python-flask-app-leading-zeros-in-totp-error-python-2-7
But the subtle issue is that the library doesn't enforce the token length. By casting a string/int to an integer, you discard the leftmost zeroes and hence could allow
1if the token was actually000001.https://github.com/tadeck/onetimepass/blob/master/onetimepass/__init__.py#L216
I suggest adhering to string semantics to avoid accepting potentially invalid input, and adopting a length constant time equality check when testing input against a candidate token here to eliminate timing side channels: https://github.com/tadeck/onetimepass/blob/master/onetimepass/__init__.py#L268