Cryptography Stack Exchange is a question and answer site for software developers, mathematicians and others interested in cryptography. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I was checking the RFC's after wondering for some time. In RFC 4226 - HOTP: An HMAC-Based One-Time Password Algorithm, it states on the appendix:

A simple enhancement in terms of security would be to extract more digits from the HMAC-SHA-1 value.

For instance, calculating the HOTP value modulo 10^8 to build an 8- digit HOTP value would reduce the probability of success of the adversary from sv/10^6 to sv/10^8.

This could give the opportunity to improve usability, e.g., by increasing T and/or s, while still achieving a better security overall. For instance, s = 10 and 10v/10^8 = v/10^7 < v/10^6 which is the theoretical optimum for 6-digit code when s = 1.

While checking implementations, I don't realize what's the problem with extracting 8 (or more) digits from the HMAC-SHA1 result.

Is this merely a matter of improving the user experience by saving the user from writing 10 digits instead of 4? or is there a mathematical reason that I'm missing?

share|improve this question
up vote 5 down vote accepted

Why stop at 8 digits? 10 digits will be even more secure. Or 12. The output of the HOTP algorithm is 160 bits so you could go all the way to about 48 digits.

Bottom line: 6 digits is secure enough for most applications and that is all that counts. Any more is inconvenient for the user and slightly more expensive when used in a hardware token (8 digit display versus 6 digit display) .

share|improve this answer

It is for user experience reasons, as you surmise, but the security is not compromised as much as you may think.

Most implementations use 6 digit HOTP/TOTP schemes and design their implementation of the scheme to give them a security level they are comfortable with.

For HOTP, the key parameter that allows 6 digits to be secure enough is the throttling behavior. When combined with a sensible look-ahead window size $s$, the probability of a brute force attack succeeding is low enough as the account or client will be unable to attempt a large number of guesses.

The throttling argument for TOTP is the same, as it is based on HOTP. The security calculation differs but the same principles apply.

The converse of course is that inappropriate selection of look-ahead/behind or throttling behavior does indeed open up a 6 digit decimal OTP to brute force attacks with high probability of success.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.