Why not just generate random strings for one-time password (OTP)? http://en.wikipedia.org/wiki/One-time_password#How_OTPs_are_generated_and_distributed

Why have so many methods to generate OTPs, why not just use just random strings?
Just using random strings is simple and often reasonable solution. However, if you have significant customer base, it can become too expensive, because all of those random strings need to be stored.



But in short, these more complex schemes are mainly for reducing storage requirements and amount of entropy needed. Note: I am partially building this reply on previous two replies.

Reducing required entropy and storage requirements

Just generating random strings means need to generate and store lot more random bits than many of more well thought OTP mechanisms. For instance, S/KEY needs to generate and store just one value, even there can be e.g. one hundred passwords, thus reducing storage costs to one (theoretically) up-to one hundredth of random strings. Because less random bits (entropy) are needed, the OTP mechanism is easier to test and validated.

(Note: to handle transitions and expirations smoothly, usually more than one value needs to be stored.).

I agree to some degree with md_1976, however, I disagree on amount of information stored on the server. Time-based OTP schemes typically still need some information on user account, like serial number of user's authentication device (hardware device). In case there is software implementation of time-based OTP, server likely needs to know the public key of user's device or possibly the server and device needs a shared secret. One possible issue with time-based OTP schemes is that they tend to require special client-side software or hardware. One the other hand traditional OTP schemes can work even just via e.g. letter and phone network. 

In time-based scheme with client side hardware device, typical information to store per account could be serial number and or other identification codes of the device.

Sizes of stored values

For purposes of comparing cost. (The possible other values e.g. account id or timestamps not considered.)


Original S/KEY (RFC 1760) - this is based on MD4 hash function, which is considered broken. Not recommended to be used.
OTP (RFC 2289), based on MD4/MD5, or SHA1. 64 bits storage needed, per OTP key.
HOTP (RFC 4226): Shared Secret is 128-bits or more (recommended 160-bits).
TOTP (RFC 6238): Uses same sized shared secret as HOTP.