I tested much higher rates for short bursts, and wasn't ever rate limited, but didn't want to risk blowing anything up. However, with a few AWS instances / lambdas it would have been possible to do it in a few mins.
Secondly, and more importantly, I found a variant (mentioned in the article) that allowed me to do this before meetings started, so you could have the password in advance.
On a single machine with 100 threads. But imagine what NSA (or any other relevant intelligence agency) can do for listening into some foreign government's meetings like the UK one in example. Or what huge corporates can do for corporate espionage.
I agree, but the point I'm trying to make is that the time to guess the password isn't too big of an issue for passwords that never change. Ideally, Zoom would generate a password for each instance of a meeting.
Failing that, having some better factor for authentication (known email or number for a given company's Zoom setup) would make it harder to get in simply by guessing a short password.
That's on just one computer. Depending on how many servers (read: how much in AWS credits) you have access to, you could parallelise it nearly infinitely.
250 minutes to crack any password?
Meeting will be over before this happens.