Isn't it easily fixed by making IDs slightly higher entropy, and also rate limiting retries? Something like a Youtube ID which is 11-char in Base62, which is short enough but has so much entropy that even know with billions of videos, entering a random ID will most likely not work.
You should also always have some reasonable rate limit of any sort of API query, if someone is querying rooms at 10qps or more, there's clearly something wrong.
I wouldn't be shy about betting the reason they haven't done this is because they don't want the ids to be longer/have a larger character set than they have to be, because they'd take longer/be more error prone to type/say out loud. Lowest possible friction: the reason for most of their flaws thus far.
I would disagree about "always" polar opposites. For example SSO/iDP like Okta add a ton of security but also makes it easier while more secure for employees to log in to their multitude of company apps.
I think the catch is that people only notice when they're opposites. If making something more secure also improved the usability (or didn't harm it), then things would (generally) be done the better way. It's only when there's tension or compromises to be made between the requirements that we actually see it, and start to think that they're opposites - because in those cases it is.
While I agree that things like SSO can be more secure and more convenient for the user, that doesn’t actually make them more convenient overall. In your example it’s mainly the fact that Okta has abstracted away the complexity so that businesses don’t see it.
I’m open to being proven wrong, and as eythian implied, I may in fact be subconsciously cherry-picking times where security and convenience were opposites and missing times where they were not, but even with that awareness no counter examples are coming to mind.
They could also just generate 4 words and string them together as the password. Considerably more entropy than 10 digital and easier to communicate too.
You need the ability to enter the code on a numeric keypad when dialing in from an office phone. Compatibility with "ancient" enterprise practices is also important.
Why not a word-based code for most people, and a numerical one for places that need them (can be enabled/disabled in the tenant), and only allows for phone connections?
Using american-english dictionary from aspell [1] and filtering for lines that only contain lower case letters [2] gives you 77649 words. For four words that gives approx 64 bits of entropy [3].
[1] Probably available on a Linux system at /usr/share/dict/american-english
You should also always have some reasonable rate limit of any sort of API query, if someone is querying rooms at 10qps or more, there's clearly something wrong.