search

bdauvergne / python-oath

Python implementation of HOTP, TOTP and OCRA algorithms from OATH
BSD 3-Clause "New" or "Revised" License
128 stars 35 forks source link

Incorrect OTP (rare) #7

Closed JBionics closed 11 years ago

JBionics commented 11 years ago

Good Test:

hotp("fb9cda921c82d893d9cdc6d6559997b1","132974666","dec6") '562487'

Bad Test:

hotp("fb9cda921c82d893d9cdc6d6559997b1","132974666","dec8") '7'

Occurs with specific key and counter combinations. Above test case shows one. Expecting an 8 digit OTP, not single digit. Happens every few dozen times I generate a random key and counter pair.

bdauvergne commented 11 years ago

I believe that your case is fixed now, but I'm not sure as the spec is imprecise on the handling of 8 decimal code, it is said that an implementation should at least provide 6 characters (implying that sometime it cannot) but in the OCRA test vectors there are test code padded with 0 to make 8 characters, implying that in case the truncation decimal representation is less than 8 digits we should pad it but the HOTP specification do not talk about padding. Tell me if you know better.

JBionics commented 11 years ago

Other OTP Generators produce a full 8 digit OTP for the test case I outlined above, that's why I thought there may be a bug rather than just an ambiguity in the spec.

http://obovweb.appspot.com/ With: Secret = fb9cda921c82d893d9cdc6d6559997b1 Moving Factor From = 132974666 Moving Factor To = 132974666 Code Digits = 8

Produces "76345995". The HOTP python only returns '7'.

bdauvergne commented 11 years ago

My answer was clear, there was a bug that I think I fixed. But when testing your example I obtain completely different values:

>>> hotp('fb9cda921c82d893d9cdc6d6559997b1', 132974666, format='dec8')
'03562487'
bdauvergne commented 11 years ago

Maybe there is also a bug in oboweb.