# Registration Code Entropy

I'm designing a system where a registration code is generated, it is sent to the user, and then the user registers himself/herself based on this registration code into the system.

The registration code has some expiration time, so that if the user doesn't register within the validity period, the registration code will expire a new registration code needs to be generated.

Is there any standard that would suggest what should be the entropy of such a registration code?

On one hand, it should be long enough so that an attacker can't guess it. On the other hand, it should be short enough so that the user can enter it easily into the system.

• Also consider when you register for Facebook. The code sent to you can be any length as all you do is click it. You can have oodles & oodles of entropy. Does that change the question? – Paul Uszak Apr 2 '19 at 14:04
• This requires email that might not be available. My questions is more about the case, when the user needs to type the registration code manually. – user67137 Apr 3 '19 at 8:35

There are length recommendations within the HMAC-based One-time Password algorithm, which is simply explained here, and the detail is here.

The important part of this is:-

The recommendation is made that persistent throttling of HOTP value verification take place, to address their relatively small size and thus vulnerability to brute force attacks.

Just as a cash machine with a 4 digit PIN. They get angry after 3 bad attempts. RFC 4226 suggests an increasing delay after each registration failure. If you go with the default 6 digit code, you'd get a tad below 20 bits of entropy. But that's to be viewed in conjunction with throttling. The code would simply look like 872921.

Also there are RSA hardware tokens that use 6 digits, but with a validity period of only about a minute. Adjust accordingly...

Note. This form of HOTP does not mathematically link the code to the time. You'd have to implement that check separately. I don't want to dwell too much on the mechanics of generating/accepting the token. I'm focusing on the IETF recommended entropy aspect of the question within a rate limited environment.

• Don't you need a key to perform HOTP? That seems to be missing in the users system where the server generates the registration code. OK, you added that to the answer as I wrote the comment, but the key is still required at the side of the user. – Maarten Bodewes Apr 2 '19 at 14:34
• OK, but in the first sentence of the introduction of the HOTP RFC you can find "Today, deployment of two-factor authentication remains extremely limited in scope and scale" and then goes on to define a standard to be used for two factor authentication. If you use HOTP differently then you have to show how the scheme works and the benefits of doing this instead of a uniquely generated random as the user presumes in the question. – Maarten Bodewes Apr 2 '19 at 15:34
• @MaartenBodewes Doesn't the question simply ask about the length of the token and some reference to support it? I'm not suggesting any particular scheme other than 6 - 8 digits. We could use AES-IV recommendations but that seems silly compared to a cash machine PIN. – Paul Uszak Apr 2 '19 at 15:49
• Yes I ask about the length of the token and some reference to support it. In case that the registration code is the only input from the user, are 6 digits sufficient? – user67137 Apr 3 '19 at 8:40
• @user67137 Well the digit length can be increased easily a la RFC 4226. The problem is that your question is 'soft'. Only you can determine what is 'easy', what is the risk of unauthorised access to the system and how long the user has to register. You alternatively could go with a hexadecimal AES IV from a CSPRNG but that's 32 characters long! 8 numbers give you 26 bits of entropy, or a 1 in 100 million chance. – Paul Uszak Apr 3 '19 at 11:10