Traditional 2FA versus PIN + OTP

Question

I've just migrated to a new email company and they offer a type of 2FA I've never came across before.

Traditionally in 2FA you enter username and password then are presented with a screen asking for the generated code token. Sometimes you simply append the token to the password for times that a second page isn’t possibly, VPNs for example often use that.

The new company I'm dealing with has you create a 4 digit PIN and when you enable 2FA you no longer sign-in with your password but use PIN + token entered into the password field on the login form. The account still has a password for IMAP, SMTP, POP3 etc access.

This seems much less secure to me but I'm not sure if I'm right. My thinking is that a suitably complex password (let's say 32 characters of letters, numbers, and symbols) followed by the token which changes every 30 seconds is going to take infinitely longer to crack than a 4 digit numerical PIN combined with the same token.

In this case would it be more secure to use a suitably complex password without 2FA enabled that you change every couple of weeks than the 2FA implementation with PIN + token?

Note: The company itself both refers to this system as 2FA and OTP interchangeably, but I'm not entirely sure what the correct terminology should be.

Answer 1

Instead of:

1. alphanumeric password of reasonable length (36 possible characters over, let's say, a max length of 8 characters for a typical user) [does not account for special characters, but I already suspect there are other issues]
2. token

The system uses:

1. 4 digit password (10 possible characters over a length of 4)
2. token

This is demonstrably a much weaker system, even if I design a very weak password system (outlined above). Plus, the UX is odd, but that's another factor.

But, is it too weak?

The fact that the token changes every 30s mitigates a lot of problems. Having a password means that if someone gets ahold of the token generator, the account still has some protections. But is 4 digits enough of a protection?

Two risks to consider:

• Someone bruteforcing the pin+token pair

This is entirely up to how fast the system allows attempts within a 30s window. So, maybe it is secure enough. But do we really want to rely on a system throttle as a security measure? Throttles are a nice backup measure, not a primary mitigation.

• Someone bruteforcing the pin if they have the token generator

Mathematically, to go through all the combinations would take 10,000 guesses (5000 on average to find success), if entered by hand, and if we assume perfectly random pins. That's a lot of ifs. Again, it is dependent on how many attempts the system will allow. Also, pins are notoriously easy to guess.

Compare this to a 'complex password' (however you want to define that) that you change frequently. Here's the thing: without the changing token, you change the time to bruteforce from 30s to 2 weeks (in your scenario). Now, the relevant factor is the complexity (or entropy) of your password and your system to reliably change it frequently. Again, a lot of dependencies.

As you can see, it is difficult to compare the factors that you laid out. A lot of 'ifs'. For the factors that I have control over and the risks that I am worried about, I might choose the pin+token (assuming that the 2FA is implemented properly (whoops, another 'if')).

But really, I'd choose another service that can implement 2FA properly.

Answer 2

There is no need to restrict the knowledge part (first factor) to a 4 digit PIN. Unless they are using a very bad, old product in the backend. I think RSA initially did that. But hey - RSA SecurID started in 1986!

All other products nowadays allow for a "PIN", that acutally can be a password.

But there is also another aspect, you should consider:

A longer password (single factor) of course has more entropy than a 4 digit PIN and a 6 or 8 digit OTP code. BUT: Your password is stored in a password database, which sometimes... ...well, gets lost. And then the attacker can brute force the hash of your password.

Of course the "PIN" of a 2FA solutions is also hashed/stored somewhere. And also the secret key, that is used to generate the OTP value is stored somewhere else - hopefully encrypted. But these are usually different locations and different hashing/encryption methods which should not be vulnarable to the same SQL injection.

I am involved in the development of a 2FA solution, which uses different ways to store these information: http://privacyidea.readthedocs.io/en/latest/faq/crypto-considerations.html

Plus: You could even use the 1st factor (password) from another location like an LDAP directory. This way attack ways vary a lot.

Answer 3

This is the way 2FA was always done with tokens well before "two step authentication" arrived. The main concern with two step is that it leaks whether the username and password are correct before authentication occurs. There's an operational benefit in the pin-append method: it works with any front-end that supports username and password. Many VPNs etc do not support two step.