Hacker News Reader

Comment by varelaz | Hacker News Reader

TLDR: With 17 digits meeting password is not needed at all. If meeting will be 17 numbers it will be the same as to protect 11 length digit number with 6 digit password. So basically that's the trade off. One could say that password is not the same as meeting ID, but usually they both sent in one email/message and lifetime and protection for them is equal. Also it's easier to input one number than 2 different.

View on HN

Please don't think of this in entropy terms alone. There is a massive usability difference between the two.

I'm not sure I understand your point. The usability of clicking a link stays equal regardless of the amount of digits in the ID. Adding a password reduces the usability.

Security pretty much always reduces usability - that’s the trade off.

I've been thinking about security and usability for a while. IMO a big part of use-ability issues are related to interfaces people have to interact with. This is mainly concerning authentication and crypto related processes.

I generally like the idea of smartcards, or having some physical thing you carry around which is used to authenticate with systems.

Two factor auth - some physical thing you carry around with you to authenticate with systems - is the very definition of decreasing usability in order to increase security.

I think they’re referring to passwordless login with physical keys. One unphishable factor that can’t be brute-forced or cloned and doesn’t require typing and password management.

Still suffers from the same usability constraints.

To clarify, do you mean usability as "how easy is it for an end user to perform X?" I feel in general, adding security to a system without security does decrease usability.

I think focusing on "relative usability" is important too. IMO it should be able to increase relative usability AND security.

For instance, I find unlocking my phone and paying with apple pay is easier to use than taking out my wallet and paying with a card. Having my credit card information encrypted on the phone makes it harder for a thief to access, when compared to gaining physical access to the credit card.

I also use a yuibkey to store cryptographic secrets. Generally I leave it plugged into my laptop, so it does not add inconvenience to me in using it. Before I had to type in a long password to decrypt my SSH key. Now it's stored on a YubiKey, protected by a shorter PIN, and requires a physical touch to perform cryptographic operations. By moving cryptographic secrets from a system with a large attack service (the laptop) to a device which requires physical access and has a smaller attack service(the yubikey), I find the system is easier to use, while increasing security.

One could argue a lack of security can lead to a decreases usability. Ex, a system under a successful DoS attack makes the system not very useable. I digress though, as I do not believe this is what you were getting at.

Using a card as auth is not 2FA. I've hated some 2FA methods I've had to use (phone apps, RSA tokens), but when your auth method is just a yubikey or a key card, the usability experience is pretty excellent.

An important Zoom feature is that you can dial in from a regular cell phone / landline and conference phones. That's one of the selling points of Zoom.

But when joining a Zoom call from your phone you dial a number, then enter the meeting ID. The meeting ID has the same number of digits as a US phone number, but it isn't the number you dial. The calendar invites generated by Zoom format the number + meeting ID in such as way that a user can tap them and it will dial the number and enter the meeting ID.

Basically, in both cases (computer/app or dial-in), increasing the number of digits of the meeting ID has very little impact on the users. Forcing a user to enter a password after joining (which is just more digits) does impact the user.

>Basically, in both cases (computer/app or dial-in), increasing the number of digits of the meeting ID has very little impact on the users.

It is a frequent use-case that people join meetings from devices that are not running a calendar application, or the calendar does not have the meeting invite.

For example: conference rooms.

The one-tap feature only works on iOS (<15% of cellphone market), although I would assume that it's higher in the enterprise space. There are also conference room telephony systems where there is no one-click solution.

> The usability of clicking a link

The situations and use-cases behind meeting-software are such that you can't rely on this.

There are many situations where you want to transcribe the information. For example, dialing in as voice-only with a private phone based on an e-mail on your work-laptop.

Or perhaps a conference room at a client-site where the client-guy has their corporate-approved presentation laptop, but he can't find the e-mail/chat message with it. Meanwhile you've got it up on-screen, but your device is not approved for any kind of internet connection in this part of the labs, and even your phone has no signal. (Yes, I've been there.)

The other day my wife got an e-vite with a link to a zoom meeting, but the e-vite software will prerender all the text to an image, so the link had to be copied in :(

Do it in base 9000 with baby names and common words. "Join us in black raven deodorant daisy mega delta leo"

Also create dud rooms with prerecorded conversation.

or honeypot rooms with soft porn

or honeypot rooms with super secret sounding military talk

Actually, what would be really wild would be to group the wardialers into a meeting and sell them product. This process will no doubt keep them busy and reduce teh attack surface.

If you don’t separate the access key from the secret you can’t change the secret if and when it gets compromised.

Neither one is secret if you send them both to every recipient at the same time.

One way they're different is with an ID and password you can lock people out of meetings. With just an ID other than rate limiting clients there's no way to tell an authorized connection from someone war dialing the number.

Privately issue a certificate from the organizer and don't just have a link anyone can join.

This makes it hard to have meetings with varying parties.

It seems to me as if having a password could be a useful feature to get additional features for a call. For example, a webinar host could give a password to a select few authorized to use camera/mic during the call, and just the meeting code to all other spectators. I'm not too familiar with zoom, but this feels like a better application than just two-step call joining.

Reply on news.ycombinator.com