Literatecode

There is the draft standard “HOTP: An HMAC-based One Time Password Algorithm” as a result of OATH efforts. Putting aside political issues this current draft does not sounds proper to-be-a-standard. The proposed algorithm is good but the draft covers only a very simple case yet leaves the rest to assumptions.

For example the draft describes generation of a digits only OTP and mentions alphanumeric as an enhancement. However it does not describe the standardized way to convert extracted 4-byte dynamic binary code to a proper HOTP value of required length in this case. It is not as obvious as it may look at a first glance. Assume we need generate a 6-char HOTP using a 16-char alphabet. Shall we apply mod 10^6-1 as it described in the draft, mod 10^6, mod 10^7 or mod 16777216? In first two cases we will have HOTP shorter than required; in the third case about half of values shall never be generated. The last mod is an accurate one but it is obviously not a 10^digit case.

Absence of some versioning scheme for future backward compatibility is something that the current draft totally lacks of. Imagine some enterprise deployed “OATH compliant” OTP solution few vendors already started to sell. Then some day an updated/modified HOTP standard pops up and enterprise should upgrade their servers and replace all issued OTP devices all together at once. Yeah, low cost indeed. Or how about digits-only OTP for HR department and alphanumeric OTP for financial department? Should we have an OTP server per policy then?

The draft has a lot of detailed analysis of algorithm’s security in Appendix A. Surely it looks impressive but how is it relevant here? It is a standard we are talking about, not a research paper.

Besides the draft is a quite slipshod work. There are few leftovers from the previous editions there. For example:

Let Sbits = DT(HS)   //  DT, defined in Section 6.3.1

There is no such section in the document at all. Luckily the definition is just few lines below this reference.

* The MSB of DBC1 is 0x50 so DBC2 = DBC1 = 0x50ef7f19

Where this DBC2 came from and how it relevant to the most significant byte of DBC1?

The reference Java implementation from Appendix B has some checksum calculation routine while the document itself has not even a single word about it and its usage with OTP

The test data “123456787901234567890″ from Appendix C has the second “7″ by error and it can be clearly identified by its given hexadecimal representation and the test results.

Call me picky but it is not something an appropriate standard should look alike.