Hacker News Reader

Comment by ehsankia | Hacker News Reader

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.

View on HN

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.

A phone number is already 10 digits. As long as you put proper break characters between the groupings it's not hard to read IMO.

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.

English-specific tho

Not hard to do it for any language. And they're cheap to make.

    Your memorable phrase is 'correct horse battery staple'.
    
    <copy>     <generate new phrase in $LANG>

Its not often that people without a common language have zoom meetings anyway

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.

Ah, that makes a lot of sense. I'd never considered that!

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?

This is exactly what jitsi does

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

[2] '^[a-z]+$'

[3] log_2(77649^4)

Kind of like the what3words approach to GIS

[1] https://what3words.com/about-us/

Agreed.

I will add: security and convenience are always polar opposites.

The most successful companies are typically the ones that can get away with being as convenient as possible for the longest.

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.

An excellent point, and I’m hoping some examples come up to show that convenience and security actually can be in the same direction.

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.

Zoom meeting ids have to be enterable in the phone bridge

speech recognition's probably good enough if you pick your dictionary well

Across a range of accents and such, I'd be surprised.

Reply on news.ycombinator.com