Zoom will enable waiting rooms by default to stop Zoombombing
techcrunch.comExcept waiting rooms have a separate security problem https://citizenlab.ca/2020/04/move-fast-roll-your-own-crypto...
So attackers have now ~24 hours to exploit this unpublished security issue before the second stage, required passwords, becomes active.
Hopefully passwords are implemented in a way to slow down brute-forcing. I guarantee the majority of them will be a simple word or number sequence.
Thanks for highlighting this, i totally missed that there is waiting room security issue pending disclosure.
TLDR: there’s a security issue that has been identified with regard to waiting rooms, and it has been reported to zoom. No further details will be provided until it’s fixed.
"Building development teams that include skeptics and realists, rather than just visionary idealists, could keep ensure products get safeguarded from abuse before rather than after a scandal occurs."
On the face of it this sounds fair, but the problem is that being "sceptical" and "realistic" is far easier and requires much less effort than being "visionary"[1]. Too much of the former early on can really suck the life out of a team, increasing the risk that the product fails, or is simply never built.
Safeguarding from abuse is much better achieved by systematic thinking and discipline (which are learned skills) rather than hiring "realists" who might simply turn out to be whiners and energy vampires.
As much as Zoom is currently in the spotlight, and I can't say I'm overjoyed by a number of the issues I've read about (e.g., encryption keys being passed through Chinese servers?!??), many of them are the problems of success, and every successful company has or will experience their fair share of those.
[1] I might also add that it's far easier to commentate and to critique than to do, eh, TechCrunch?
I'm so tired of these types of comments. "The reason you have this issue is you're missing X", "Yeah but if we only had X we wouldn't have been able to do this at all!", "Yes, which is why I said you should have more X, not completely abandon everything but X".
Let's be clear: The issues that Zoom is having were seen by other businesses in the same industry decades ago. At a time where every other messaging system in the world has been moving to end to end encryption - even facebook, Zoom is still lying about it to customers. It doesn't require a room full of sceptics to figure that out, it requires some sort of development process that involves a the tiniest bit of thought before rushing out a feature - a culture that is apparently consistently lacking in large parts of silicon valley.
Btw, If you think that what we've seen over the last few years is that commentating on tech is an easy career to make a living at, you haven't been paying attention to the state of journalism.
I really shouldn't rise to this but, OK, let's do this.
The comment I quoted by TC was clearly intended as a general point with broad application across tech companies, not just Zoom. Now either TC meant that, in which I disagree as outlined in my previous comment, or they didn't, in which case it's sloppy phrasing and journalism.
> Btw, If you think that what we've seen over the last few years is that commentating on tech is an easy career to make a living at, you haven't been paying attention to the state of journalism.
I said it was easy to commentate or critique (it is, and it happens on HN all the time). I didn't say it was easy to make a career out of it nor, frankly, do I think it should be. There are far too many lazy, bottom-feeding media outlets in the world and not nearly enough good ones, so I will not shed a tear for the demise of the former.
To address your specific points about Zoom: it is demonstrably false that "every other messaging system in the world has been moving to end to end encryption".
Microsoft Teams does not implement end to end encryption for audio or video meetings because they can't: they support dialling into meetings using the plain old telephone system meaning that the back-end services become an endpoint and have to be able to decrypt traffic. Sure, Teams could do it for text chat (and it's even a suggestion on UserVoice: https://microsoftteams.uservoice.com/forums/555103-public/su...) but, as far as I'm aware, they don't even do that yet.
Whether that's a big deal or not depends on your use case.
That Zoom lacks E2E encryption is not the problem: that they claimed to implement E2E encryption when they don't is. Contrast with Microsoft, who don't claim E2E encryption for Teams and, as a result, there is no significant controversy.
Some people and use cases do need E2E encryption but, for many, the trade-offs aren't yet worth it.
As already highlighted you lose support for POTS, which in my experience is used pretty regularly: e.g., people on the move, or dialling in from outside the organisation.
Another example: I suspect E2E encryption would make it difficult, even with modest numbers of participants to implement Zoom's gallery view because they'd have to send all encrypted streams in full to all participants, and clients would have to decrypt and decode all video streams. Even if it didn't prove overwhelming from a bandwidth perspective, it would eat CPU and drain battery life very quickly. Without E2E you can decrypt and multiplex on the server side then re-encode and re-encrypt to reduce bandwidth usage over the network and resource usage on clients.
Of course, this isn't insurmountable: clients could send two encrypted streams, one hi-def, and one for gallery view, and the server could route them to clients as appropriate depending on their viewing preferences. Still, this probably isn't as efficient as dealing with it on the server side.
(Obviously you might not care about gallery view, but it seems really popular for remote social gatherings.)
It's all about trade-offs: for virtual pub with my friends, I don't really care about E2E encryption, but gallery view is really great. I don't even care about E2E encryption at work that much - certainly not enough to make it more difficult for people to dial in to meetings.
But, as I say, none of this is the issue: the issue is the claims Zoom are making about their product.
1) false claims are a indeed problematic because they erode trust in Zoom
2) having no E2E is more dangerous in Zoom than with other software
For example, there is no E2E in Teams, but we have it running on servers in the same country with no direct US/CN connection. Or even better: run it on your own servers in a DMZ. Then, E2E is not so crucial any more.
This is all emotionally subjective clap trap.
So you were right, you shouldn’t have bothered.
Websites have always been the least interesting tech out there. Nuclear powered cars and helicopters to work all over again. Pipe dreams. Circular fetishism of ones cleverness.
Of course, it’s low hanging fruit relative to hardware. It attracts a lot “visionaries” who don’t realize they’re just peddling a different form to collect the same details as the last guy. And using stats to curve social agency. Good job, Nielsen.
Middle men in the flow of financial capital. Grifters of the highest order.
I host my own shit now, providing basic frontend to family & friends. They’ve all dumped private Corp services in their personal lives. Once it’s polished I’ll be publishing the setup and HOWTO videos.
Oh look how hard it all is! Better externalize all real effort in my life!
Traditional values “distract people from their life to build your ego fluffing flock rather than teach self sufficiency.”
Web companies can fuck off.
I don't know why skepticism and realism are viewed as "easy" when both are skills that require practice and education to apply accurately and consistency. What is so much harder about being "visionary" if all that means is coming up with ideas? Obviously what's valuable is coming up with ideas that can be executed on safely and easily, and Zoom completely shit the bed on safety here.
A team full of visionaries will never get anything shipped at release quality. I've worked with plenty of them. You don't need to hire a bunch of depressing pessimists but if you don't have skeptics and realists to keep your team's velocity under control you're never going to hit quality targets.
Imagine there being multiple valuable skills in an industry, like critique, commentary, planning, debugging, testing, engineering, design, and ideation!
yep, @bartread was railing against a constructed dichotomy (realist vs idealist) as if it represented the entirety of possibilities, forgetting that those idealized poles are fractions of every person's existence, not identities that confine each of us into one camp or the other.
the best visionaries (musk, bezos; not zuckerberg, thiel) combine idealism (hey, look at what could be!) with skepticism (hmm, why wouldn't that work?) to push the boundaries of invention.
I see some people running meetings who can barely find the chat. I'm not sure I trust them to manage a waiting room.
Giving the benefit of doubt here, if you enter full screen mode chat opens in a different window and no longer gives you notifications. At least on linux. I honestly find this quite painful and rather surprising. I'm not sure why full screen and chat isn't equivalent to just maximizing the window (where the chat is on the right and users are above) with tabs to open and close chat (and users). New windows seems like a weird decision.
> Starting April 5th, it will require passwords to enter calls via Meeting ID
A meeting id with a password is semantically the same as a longer meeting id (or a meeting id with a character space larger than just digits). I wish they'd do that instead (make meeting ids longer) so I could continue to enter my company meetings with only a link but not have to worry about getting wardialed.
You will be able to enter with only a link, the url looks like:
https://tenant.zoom.us/j/123123123?pwd=QlR0cXZkYXBDS0txYzJRR...
The password is an encoded version of the password set by the host.
meeting IDs need to be numbers to make it easy to join meetings by phone. no particular reason they can't be longer though.
Except the search space is much, much, larger.
Don't we want the search space larger? That way it is harder to wardial? YouTube has 11 characters composed of [a-Z] and [0-9]. (26*2+10)^11 is a pretty big number. There's no reason it couldn't be longer.
It would also make it harder to dial by phone, if you need to do so.
Yep, exactly, I think it's beneficial and the right move.
What is larger than what?
With the most straightforward way for "meeting id with a password" and "longer meeting id" to be the same, both methods provide the exact same expansion in search space compared to the previous implementation, and they have the exact same search space as each other.
(That method being: concatenate shortid and password to get longid)
Here’s an ignorant question. I see this comment all the time, that an ID and PIN is exactly the same as a longer ID, but is it actually true?
I get the logic of it, but in a practical sense doesn’t it have the potential to be different? For example, if you have to enter a correct ID, wait, and then get prompted for a password, couldn’t that potentially slow down an attacker?
Alternately, couldn’t a bunch of correct meeting ID’s followed by incorrect PINs present an opportunity to flag the ID as under attack, or give a prompt to a host that would spur inquiry, or something?
Perhaps I’m wrong about this but it seems like there are some non trivial differences between the two.
There is no reason you couldn't implement rate limiting under the "longer ID" scheme.
Sure, but your rate limit would be for all conferences.
The idea being by separating the conference number and PIN number you could limit the ability to attack a specific user ID more easily.
So we have to look at what "attacking a specific ID" even means.
With separate room numbers and PINs, it means you know the room number but not the PIN. Simple enough.
But in the long-id scenario, that means you have part of the ID, but not all of the ID. That's pretty unlikely to happen. Instead, situations where someone would have leaked the room number will take one of two routes: either the person leaks the longer ID, and there is no attacking necessary, or the person realizes that the secret code needs to be secret, and nothing is leaked at all. Either way, attacks on a specific conference ID no longer happen.
you can put the password in the link.
I work for a large multi-national media company, and we've been using BlueJeans for video conferencing for the last few years. It's been very reliable, but I haven't heard of very many others using BlueJeans. I'm curious if the security issues in Zoom vs its competitors more have to do with the amount of people using it and putting eyes on it.
> I haven't heard of very many others using BlueJeans
I'd think more eyes on Zoom right now will be better for it in the long run. Anecdotally, security aside, I've found Zoom to be about one step ahead of BlueJeans in pretty much every way.
I was sent a link for them about a month ago. On Mojave the app kept crashing. I couldn't figure out how to join via the browser, so we switched to zoom.
We use both Zoom and BlueJeans at work, and Zoom Just Works™ while BlueJeans has all sorts of compatibility headaches; if it's not Chrome/Windows, it's pretty much a crapshoot.
That being said, the AV quality between the two are pretty similar.
I found the quality and ease of use better with zoom, it's probably security through obscurity in the case of zoom vs BlueJeans though.
Bluejeans seemed to be running into audio issues as we leaned on it heavier recently
We used BlueJeans at my previous job and it was reliably awful. So many issues with it.
I'm using Jitsi now and am quite happy with it.
I've used BlueJeans extensively and I completely agree. I believe that it doesn't have a free tier though and this limits its adoption.
I also do not believe that it claims to have E2E encryption or anything like that.
Red Hat uses Blue Jeans for their webinars, and the OKD project uses it for the WG meetings. Not sure about internally or other projects as I don’t have experience with them nor am I an employee.
Did Red Hat use Blue Jeans before being acquired by IBM?
yes
same.
we've had a few glitches here and there but overall highly reliable. The ability to do a meeting or do an event to prevent zoom bombing type issues is wonderful.
Techcrunch links seem to redirect through guce.advertising.com nowadays, which is blocked by my ad blocker. Also, according to redirect-checker.org it takes 5 requests before finally landing on the actual page. Seems excessive.
I’ve used a lot of these tools, and I have to admit, Zoom is the best.
As for the Zoombombing, I can’t say that I am surprised. All you really need is the URL.
And all the other tools are like that too. Sure, you can require a separate passcode, but damn it, it’s like trying to figure out rocket science to enter the passcode.
1) you have to dial the number
2) you have to punch in the meeting ID
3) you have to punch in the passcode.
4) ERROR. You flipped it, and used the passcode for the meeting ID instead. Aargh.. frustration.
5) Forget about the passcode. Just let everyone in that has the meeting ID. And monitor if there’s someone unknown on the line.
> you have to dial the number
It must have been at least a decade since I actually dialled into a video conference using a phone, on any conferencing platform - I always connect audio via my laptop or phone, which I use with a Bluetooth headset.
I was actually having this conversation with a bunch of colleagues the other day, and every person in the call said the same thing, only difference was some used a USB headset, rather than Bluetooth.
Waiting rooms don't help because you don't see any identifying information. My sister's call got zoombombed even with a moderated waiting room. They were trying to keep within their university's students, but they couldn't see the email addresses associated with the zoom user name in the waiting room, so a griefer got through.
Zoom meetings created on my company's account can only be joined by people logged in through my company's SSO (unless the meeting is explicitly set to open).
Universities typically have SSO, so this don't seem like a hard thing for them to implement.
For these cases required sign in might be best
Seems like User Interface design issue.
At the minimum they could show anonymized email id: ab<..hidden..>gh@univname.com
Hopefully they do this for existing users as well. One of my fellow teachers' classes got bombed today even after we were all sent instructions about securing our meetings, enabling waiting rooms, etc.
She didn't follow the recommendation because she "didn't think someone would join" because she hadn't posted the meeting link on social media. You have you protect your users that won't protect themselves.
Wouldn’t it have been easier to present an option to the presenter once X number of people joined? So 3-5, no, but more then a dialog pops up asking the presenter if they’d like to have a waiting room.
My understanding was that chats simply had too easy to guess names.
Would this be solved by generating chat names through a cryptographic hash algorithm?
I have google docs that are edible by anyone with the link and I’m kinda assuming that the link is as hard to guess as logging in with a password.
Am I completely off and in dire need of reevaluating my personal web security?