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 get 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.

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.