Only peripherally related but after the recent Robinhood fiasco I downloaded the Interactive Brokers mobile app, and they send your login user/password in plaintext:
So 12 characters is not secure, 4 numbers is not secure, 6 numbers is not secure either. 5 numbers is the best security!
They've got a custom OTP setup which they've revised at least twice already, but as with this Clubhouse thing if you transmit your OTP as plaintext over unencrypted channels obviously a bad guy can intercept that. So basically that SSL box ought to be removed (in favour of always doing TLS) or at the very least default checked.
I can most easily imagine they had a proprietary setup in the 1990s, and one day they make a web site because of this exciting new technology. Should it have SSL? Security sounds good, but it is slower. Traders demand an option. Now, fast forward a few years you're building an iPhone app, your prototype looks good, but traders ask, where is that SSL option? Chances are the answer is "Um, TLS is always On? Because switching it Off would be stupid?". Oh dear, are you calling a long time customer "stupid" for not clicking the SSL box all these years? No of course you aren't, you add the SSL box to the app and everybody working on it learns not to point out that this is stupid.
[ Do I trust that they got that right? Maybe. Others might have a better idea how many off-the-shelf OTP implementations handle this correctly ]
However an active MitM just works. You give the user the illusion they're talking directly to the real system, but you actually keep working copies of their logged in state. When they're done trading, you just carry on. If there's an explicit "Log out" step you can dummy that out.
Forget passwords and OTP, even something modern like Security Keys (WebAuthn) would fall to this - except WebAuthn's APIs magically don't exist unless you have secure context (basically an HTTPS site) so for the web that can't happen. If you used the built-in Android / iOS FIDO implementation† and stupidly did HTTP backend in your app, you'd be screwed.
† In this scenario, you're getting the same features as WebAuthn but backed by your device biometrics, and with a custom per-app identifier instead of a DNS name to stop you stealing the user's Google authentication or whatever.