Open swansontec opened 6 years ago
Interesting. I never had this issue for the past few years. I will take a look.
Ah, my test vector does not actually trigger the issue. The odds of triggering this issue are about 1/20000, since final hash output needs to be less than 99999 (out of ~2 billion possibilities). I will attempt to find a test vector that does trigger this problem.
Try it with the base-32 encoded secret AAAAAAAA
and counter=41952. The output will be 5 digits long, not 6 digits long like it should be.
Try it with the base-32 encoded secret AAAAAAAA
and counter=41952. The output will be 5 digits long, not 6 digits long like it should be.
The following code should solve the issue:
const padding = Array(length).join('0')
return (padding + codeStr).slice(-length)
This tacks a bunch of 0's in front of the number, and then trims it down to length
characters.
When initializing RFC4226 with the base-32 encoded string
AAAAAAAA
(i.e. 5 bytes of 0's), the HTOP for counter=2 should be "073348", and the HOTP for counter=9 should be "003773". The following code does not appear to produce the necessary leading 0's: