The HOTP algorithm provides a method of authentication by symmetric generation of human-readable passwords, or values, each used for only one authentication attempt. The one-time property leads directly from the single use of each counter value. Parties intending to use HOTP must establish some ; typically these are specified by the authenticator, and either accepted or not by the authenticated:
A counter, C, which counts the number of iterations
A HOTPvalue length, d
Both parties compute the HOTPvalue derived from the secret key K and the counterC. Then the authenticator checks its locally-generated value against the value supplied by the authenticated. The authenticator and the authenticated increment the counter, C, independently of each other, where the latter may increase ahead of the former, thus a resynchronisation protocol is wise. RFC4226 doesn't actually require any such, but does make a recommendation. This simply has the authenticator repeatedly try verification ahead of their counter through a window of size, s. The authenticator's counter continues forward of the value at which verification succeeds, and requires no actions by the authenticated. The recommendation is made that persistent throttling of HOTPvalue verification take place, to address their relatively small size and thus vulnerability to brute force attacks. It is suggested that verification be locked out after a small number of failed attempts, or that each failed attempt attracts an additional delay. 6-digit codes are commonly provided by proprietary hardware tokens from a number of vendors informing the default value of d. Truncation extracts 31 bits or ≈ 9.3 decimal digits, meaning, at most, d can be 10, with the 10th digit providing less extra variation, taking values of 0, 1, and 2.
Bidirectional authentication
After verification, the authenticator can authenticate itself simply by generating the next HOTPvalue, returning it, and then the authenticated can generate their own HOTPvalue to verify it. Note that counters are guaranteed to be synchronised at this point in the process.
HOTPvalue
The HOTPvalue is the human-readable design output, a d-digit decimal number : That is, the value is the d least significant base-10 digits of HOTP. HOTP is a truncation of the hash-based message authentication code of the counter, C. Truncation first takes the 4 least significant bits of the MAC and uses them as an offset, i. That index i is used to select 31 bits from MAC, starting at bit i + 1. Note that 31 bits is a single bit short of a 4-byte word. Thus, the value can be placed inside such a word without using the sign bit. This is done to definitely avoid doing modular arithmetic on negative numbers, as this has many differing definitions and implementations.
Tokens
Both hardware and software tokens are available from various vendors, for some of them see references below. Hardware tokens implementing OATH HOTP tend to be significantly cheaper than their competitors based on proprietary algorithms. As of 2010, OATH HOTP hardware tokens can be purchased for a marginal price. Some products can be used for strong passwords as well as OATH HOTP. Software tokens are available for all major mobile/smartphone platforms.
Reception
Although the reception from some of the computer press has been negative during 2004 and 2005, after IETF adopted HOTP as RFC 4226 in December 2005, various vendors started to produce HOTP compatible tokens and/or whole authentication solutions. According to a paper on strong authentication published by Burton Group in 2010, "Gartner's expectation is that the hardware OTPform factor will continue to enjoy modest growth while smartphone OTPs will grow and become the default hardware platform over time."
