I've noticed that many services that offer 2 factor authentication have jumped from using four digits to six. However, it seems counterproductive to me because the digits are random, the digits (should) expire, and with six digits, you may have to look at your phone twice or more
Is there any reason for this, beyond it seeming more secure? My preference would be four or even three digits as they are easier to remember and re-enter.
Yes, there is a reason - to reduce brute force guessing attacks against multiple accounts.
High quality 2FA implementations include an online component that enforces a limited set of retries, ensuring the account is locked out long before an attacker could try all possible passcodes. The length of the 2FA passcode establishes the probability of a malicious actor guessing the authentication in the given number of attempts allowed. For example, if the 2FA passcode is 3 digits long and you are given 3 attempts to enter it, the chances of randomly guessing it are 3/1000, or 0.33%. If the 2FA passcode is 4 digits long, the chances drop to 3/10000, or 0.033%.
While this is certainly a low chance that he'll guess your specific passcode, imagine an attacker with a database of 10,000 accounts stolen from some server. Attacking just one user account, he only has a 0.33% chance of guessing it, but after guessing three times each on 231 different accounts, the probability he'll successfully guess one is 0.5, or 50%. By the time he's locked out 1,533 accounts, the probability he successfully guessed at least one valid passcode is .99, or 99%.* Consider the attacker may not need to successfully attack all accounts in order to gain access - he may only need one success in order to log in to the site and establish a foothold.
Traditionally, detecting a brute force attack relied on recognizing the attacker trying multiple requests quickly with an automated script. An IP address that is responsible for three or ten locked-out accounts in a row might trigger an alert. But modern attackers know that by proceeding slowly they can avoid detection; recent advanced attacks have demonstrated this technique in the wild. Consider an attacker using a botnet of 10,000 zombie computers. He can command them to slowly launch one random request every few minutes from all 10,000 IP addresses without ever tripping a velocity alert or locking out any account. It's only a matter of time before he succeeds.
Since detection of this attack is virtually impossible, the only protections left are to make it harder on the attacker, so the odds of correctly guessing a passcode must be reduced. The two ways to do that are to increase the minimum length of a passcode (to 6 or 8 digits,) or to reduce the number of invalid passcode attempts allowed. Since reducing the number of guesses would impact usability for the legitimate users, algorithm designers have little choice but to increase the length of each passcode.
* Check Fabio's answer for further clarification of the mathematics behind these numbers.
John Deters's answer explains why using more digits for 2FA codes is a good thing, but he hasn't shown the math. Moreover, he invites readers to check his calculations, and I think there are some errors. I wanted to make an edit, but I've realised it would be way too long. So I'm posting this as a separate answer; if there is consensus that my calculations are right, we can edit his answer (or he can do it himself).
The goal is to calculate how many attempts an attacker needs to guess a 2FA code of a given length. The attacker succeeds if, making several attempts, he can guess at least one. "At least 1" is hard to calculate directly, so let's use a trick:
P(at least one code is guessed) = 1 - P(no codes are guessed)
Now, from the binomial formula, the probability of getting exactly k=0 successes in n trials is simply
(1-p)^n
so
P(at least one code is guessed) = 1 - (1-p)^n
So, for a given p=3/1000 (3 attempts before the account is locked, where the total possible 3-digit codes are 1000), what's the number of attempts n that an attacker needs to have a probability of success greater than 50%?
P(at least one code is guessed) > 50%
1 - (1-p)^n > 50%
(1-p)^n < (1 - 50%)
(I'm leaving it as 1 - 50%, instead of replacing it with the result 1/2, because at the end we'll repeat the calculation to have a probability of 99%, and in that case I want it to be clear that we don't have to write 0.99, but rather 0.01. I could have left a variable there, like desired_success_probability, but I thought it would be less readable)
Now, to extract n, let's take the logarithm to base (1-p) of both members. Since the base is less than 1, and the logarithmic function to a base less than 1 is monotonically decreasing, we have to invert the inequality, so we get:
n > log(1-p)(1 - 50%)
and by changing the base to a convenient one (for example 10 or e -
anything goes, as long as the calculator supports it) we have the solution:
n > log(1-50%) / log(1-p)
which for p=3/1000 is
n > 230.7, that is, n >= 231.
So if the probability of guessing one code is 3/1000, after making three attempts each for 231 accounts we have that guessing at least one is more likely than guessing none.
If, instead of having a probability of success of 50%, the attacker wants to reach 99%, he needs
n > log(1-99%) / log(1-p)
which means
n > 1532.75, that is, n >= 1533
What happens if the 2FA code is, instead, 6 digits long? The probability of success for a single attempt becomes p = 3/1,000,000, which means that the attacker needs at least 231,049 accounts to have a 50% chance of success. If he wants to have a 99% chance of success, he needs 1,535,055 accounts.
In short, by adding 3 digits we are increasing the number of possible codes by a factor of 1000, and to keep the same probability of success the attacker needs to make slightly more than 1000 times as many attempts. If these are online banking accounts, is it worth it to spend 1-2 seconds more to enter the code in order to make a thief's life 1000 times harder? In my opinion, absolutely.
log(.01)/log(1-3/1000) ~= 1533 for 99% with 3 tries, looks like your 511 comes from log(.01)/log(1-3/1000)/3 ~= 511 when it would actually be log(.01)/log(1-9/1000) ~= 510.
– AndrolGenhald
Aug 23 '17 at 13:45
p=3/1000 for 3 attempts with 1000 possibilities, getting 231 and 1533 for probabilities 50% and 99%, then towards the bottom you give the answers 77 and 511 for 3 attempts, presumably by dividing your previous answers by 3, but your first answers were already for 3 attempts.
– AndrolGenhald
Aug 24 '17 at 04:22
"Should", of course is subjective. And what "should" happen depends on things like the standard you want to meet, the restrictions you have, what restrictions your users have, and, ultimately, what your goal is.
The original RSA fobs circa 2003 with rotating codes were 6 digits long (no space in the middle at that time, which was annoying for my active memory), which might be what is anchoring subsequent MFA code lengths to 6 digits.
If you are talking about TOTP MFA codes ("Authenticator" codes), then RFC 4226 provides a standard: "Implementations MUST extract a 6-digit code at a minimum and possibly 7 and 8-digit code." They do not state why they must be that length, but this RFC closes the discussion for TOTP MFA.
Banks globally are moving to longer MFA codes in their various MFA implementations (same are "Authenticator"-type implementations, some are not). 6 is very common in my experience working with various institutions across a few countries.
Codes sent via SMS (remember that MFA over SMS is not the securest option) have no standard, but the UK government goes from 5-6, depending on the department. There is no reason why given, and the NCSC doesn't weigh in on that either.
Regulations and policies I've seen dictate MFA code lengths, so if you are subject to those, then you should follow those mandates. However, nothing in anything I've read attempts to justify the length (and everything I've read recommends 6 digits minimum).
Since this question was asked in 2017, I've seen services that process sensitive information do complex things with the Authenticator app and use only 2 digits. But that is likely because they are using the app itself as an authentication factor.
So, "should" is tough to answer. Longer is better for security. Shorter is better for general usability. Since 2017, the world is pretty used to 6 digits, and that's the TOTP standard. So, at this point, you might need a really good justification for reducing from the de facto standard of 6.
And before people make conclusive statements about the UX impact on any particular implementation of code lengths, it is important to actually do (or reference) UX research.
My vote is on 4 digits still being ideal for some systems.
The extra inconvenience to the average user of 6 digits is not insignificant (and enough to result in some users disabling 2FA. Disabled 6-digit 2FA is NOT more secure than enabled 4-digit 2FA).
And it is only more secure than 4 digits in one edge case, which is better secured by more direct methods, instead.
John Deter's answer explains a scenario where 4 digits may be insufficient, but only if:
1. The attacker already has thousands of your user's usernames AND PASSWORDS.
In most cases, this is already going to be a huge disaster that should be prevented (and quickly fixed, if that fails) by something less tangential (e.g.: by expiring passwords). Systems with fewer than 500 users, systems with salted hashed passwords... this case just does not apply to most properly-secured systems. Trying to manage it by adding digits to your 2FA is roundabout and indirect. Like swallowing ibuprofen for a cut on your toe instead of just putting a band-aid on the toe.
2. The attacker gaining access to even one user's account is considered catastrophic.
Some (most?) systems worth protecting with 2FA won't give a single user access to everyone's data. At most, the data of a single user is at risk (one who was careless with their password, unless there are far bigger security flaws in the system).
Since those two won't be true for many systems, I think there's still some legitimacy in the viewpoint that 4 digits is the best answer for some systems.
a) 4 digits is more than enough in competently secured systems.
Without thousands of accounts already compromised, it's plenty: 3 retries is more than enough for typos, so: 3/10000, or 0.033% chance of guessing.
b) 4 digits is enough for user peace of mind.
Most banks still use a 4-digit PIN.
c) As security professionals, we skew cautious and undervalue usability.
6 digits (or more, or alphanumeric characters) is more of a hassle to average joe than it is to us. That's 2 glances at the phone and an occasional typo. When given the choice, many people choose not to use 2FA because of this inconvenience.
Discussion about this and other problems with carelessly excessive 2FA causing security problems is easy to find, e.g.: https://www.reddit.com/r/sysadmin/comments/152rocw/is_there_such_thing_as_mfa_fatigue_because_if_so/
We often have to balance user convenience and usability with security concerns. 6 or more digits seems a bit like digging a moat in your front yard instead of just getting a deadbolt on your front door.
