One positive thing about all these horrendous security flaws that have been recently discovered in Zoom, due to its popularity, is that the company seems to be taking them seriously, recently instituting a feature freeze to focus on fixing them: https://blog.zoom.us/wordpress/2020/04/01/a-message-to-our-u...
As a consequence, I suspect Zoom's security is more likely than not to improve going forward... although it will surely take a long while. Security is Capital-H Hard.
Also, I cannot think of any other multi-video-conferencing solution that "just works" and has been as thoroughly stress-tested and attacked by bad actors in the wild at such a large scale. If Zoom does a decent-to-good job fixing all the security issues, it looks likely to continue to dominate its market.
I'm not a fan of Zoom... But the pile-on of grief is ridiculous.
The "war dialing" issue is a great example. Webex has had the exact same "flaw" for a decade, with the exact same solution - set a meeting password. Other solutions like Google Meet or Skype have the "lobby" approach.
They're not usually infinite. My father waited one out for three years, then went back into the industry for a rival firm and put his old boss out of business.
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
It’s not an egregious flaw, any more than the telephone numbering system is. It’s a design decision to improve usability that is generating a lot of noise during an extraordinary period.
Usability is the zoom priority, and the reason why people who already own more secure, no cost, solutions like Teams, Skype or Google Meet buy Zoom.
Knowing someone's phone number very obviously doesn't grant you direct access to autojoin their calls with people. At _best_ you can attempt to tell if they're currently in a call or not by calling them, but even that is far from reliable (e.g. in places where voicemail isn't as much of a thing do not disturb is sometimes implemented by pretending to be busy or switched off)
People often forgot that its a Security-Usabilty scale, with perfect security on one side and perfect usability on the other. An unplugged computer is perfectly secure, while a computer wide open is perfectly usable. But neither is usually preferable.
So there's two kinds of problems here - not all security flaws are created equal.
One kind is missing something or unintended consequences. Making all URLs clickable opens a UNC attack due to some obscure Windows "feature", for example. Or having N digit numbers means they're technically iterable, but this is the same for cellphones, and there are workarounds.
The other kind is security holes caused by explicitly working to bypass security restrictions yourself. Installing a server with webcam permissions that you don't cleanup so reinstallation is easier for you (don't be surprised when other apps start telling it to switch on the webcam), impersonating the system root password dialog (don't act surprised when other apps steal the password from you), claiming end to end encryption without being clear about where and when it's on, and others.
The first is normal security work, the second is sleazy. We all forgive the first, but we shouldn't let sleaziness slide.
Why do people keep saying it just works? It just works if you install their app, probably. But audio doesn't work at all in Firefox. That's not really just works for me.
I'm not sure about "just works", but I am sure about "works" in the sense that is head and shoulders above every other video chat app I've used when it comes to audio and video quality, especially for large numbers of participants, audio sharing, document camera sharing, multiple participants sharing simultaneously, and there are plenty more.
I've never used the web version, but it wouldn't surprise me if it's not the same experience. The video and audio encoding and decoding stuff seems like it just makes more sense as a native app. Given the number of variables that browsers, versions, sandboxing, etc. bring to the equation, I can tell you where I'd spend the majority of my efforts if I were doing video chat: on a great native app. You have a lot more control over that experience, IMHO.
Anyway, your comment reads to me like someone who will never install it, but I would encourage you to at least test out the difference to see why it's become so popular.
Yeah, the only other video app I've used that approaches the call quality is Slack. I've not tried to use that with more than a handful of people though.
Slack would be great if my team didn’t constantly have issues with it dropping audio or video altogether when attempting to connect, and that’s if the connection works in the first place! A shame, because we’d love to use only a single app for our comms...
For every N users that say something works, you will always find M users that say it doesn't. For good products the ratio of N:M (works:doesn't) is high in the direction of N (works).
So people keep saying "it just works" because Zoom has a noticeably high ratio of works compared to almost any other video conferencing software. It does not mean it works 100% of the time flawlessly for every single user ever always and forever.
FWIW, of the hundreds of Zoom calls I've had, many with non-technical people, I have yet to encounter any issues. I cannot say the same for most other video conferencing products I have used. YMMV, take with grain of salt, caveat emptor, etc.
Yea, Hangouts is a lot more "it just works" than Zoom is for me. That being said, the quality of the actual calls on Zoom is _way_ better than Hangouts.
I mean, I don't really know how "consistently high call quality" is not the most important feature of any video chat application. My experience on hangouts has always been garbage. Delays, choppy sound, my machine starts going insane while rendering other people's live video. It may just work in the sense that you can immediately use it, but if even 20% of the time you use it the call quality sucks, then it's a crap product IMO.
> It may just work in the sense that you can immediately use it, but if even 20% of the time you use it the call quality sucks, then it's a crap product IMO.
"it just works" doesn't mean "its a superior product". I use Zoom over hangouts whenever I'm on a call with more than ~3 people, but automatic gcal integration + being fully functional from a browser means that hangouts makes more sense sometimes.
(I also don't have nearly the amount of issues you do with hangouts. The biggest problem for me is how much worse they handle crosstalk, which isn't an issue when there are only a couple of people on a call.
Is Hangouts now the same as Meet, or does Google have two different products? Hangouts used to work fine back when it was integrated with Google+ (I miss those days), but I just tried to go to a meet for my son's school, where nobody could see or hear us, and Meet claimed the mic was muted by the system, while the system said it was turned on and the browser had access. That's clearly not "it just works", but apparently nothing is.
hangouts meet does 1080p (whether it works now during the covid pandemic I don't know) and is Google's replacement for the regular hangouts. it has been available for companies and has been part of g-suite for enterprise since 2017.
Where I work, it defaults the webcam resolutions to 360p and we can only choose 720p for our 1080p hardware.
Anyway, my biggest concert is with lack of fluidity of slide/screen sharing.
It is not viable for presentations with animations or where the presenter needs to point with mouse/cursor to a specific point or area of the slide (for example, a point in a curve in a graph).
I work with this.
I'm struggling with this tools first hand.
My impression is there a lot of opinions here from people which is not using these tools.
I think that in most VTC platforms, the tendency is to favor quality/resolution for screen sharing and speed/FPS for camera sharing.
It sounds like your case is less common but the idea is that a video or camera feed can handle more compression (and subsequent drop in quality) as long as it isn't choppy or dropping out. Alternately, a slide or document may have small text which would quickly become unreadable if the compression is too high. To prevent that, you get high quality but only 5FPS or whatever so people can read your document or slide.
Slides and docs don't usually need high framerates so it would just be wasteful to try delivering a mostly static, high resolution, low compression 1920x1080 feed of a PowerPoint at 15 or 30 FPS.
There are ways around this (even on a consumer PC) such as using something like OBS to switch between sources like a webcam, a video clip, or a screen cap and feed them to a virtual webcam (which can be selected in your VTC software as the webcam input). Alternately, there are dedicated switchers and mixers but they're usually reserved for studios or in-facility installations.
But again...you may not like the results even so. The webcam feed often trades higher FPS for higher compression.
We've run into a lot of this lately as well (working in a university supporting online classes for the past week or two). I know it's not ideal, but Firefox and Chrome don't seem to have this issue. Asking someone to use a different browser is annoying, but it's a workaround that seems to be effective so far.
It is even harder when you try and graft the security on after the fact. Security needs to be a consideration from day 1, not once youve your minimal product. Proper security may steer architecture decisions that may be difficult or impossible which to adapt. This is especially true for internet facing services.
I had a hell of a time bolting on authentication/permission to an internal API (not web based) at a previous employer. By the time I left, we had all users authenticating, but only maybe 20% of the API surface had permissions beyond being authenticated. It was a CRUD API over +300 objects. Yeah, everything was audited, so we couls recover from a malicious or bumbling idiot authenticated user, but the exposure was way to high with people having far more access than their roles needed. It was a mess.
Yeah... graft it on after you've lunged to make a sort of OK product and they're locked in but the vulnerabilities you're exposing them to aren't worth moving off the platform. The capitalist sweet spot
Your comment reads as an alternative form of “This is good for Bitcoin.” where its most rabid followers see nearly any news, even disastrous, as being good for it.
You are saying because they had lax security, now they will have good security.
>Also, I cannot think of any other multi-video-conferencing solution that "just works"
Another post about Zoom, another comment how it's the only video conferencing platform in the planet that "just works". You know I find that really hard to believe... not least of all because I personally use other solutions without never having major hiccups at all.
>recently instituting a feature freeze to focus on fixing them
Or they're having productivity problems like every other company right now and are spinning it to seem like they are on top of things. These security issues have been around for years.
I worked in videoconferencing for a while. When it comes to meeting identifiers, striking the right balance between ease of use and security is really hard.
On the one side, maximum ease-of-use is a name or code short enough for someone to say over the phone. "Here, just jump into the videoconferencing meeting 'mikefred' or 'john10' or '39584'". That works particularly well for small meetings where it's immediate obvious if someone else joins and you can stop talking and ask them who they are and kick them out if they shouldn't be there.
On the other hand is long random identifiers in a space large enough they're impossible to guess. If you're joining a meeting from a link then nobody cares, but if you're telling someone over the phone or typing it into the phone it sucks. (And you are very often needing to jump from one form of communication to videoconferencing, where there's no way to "just paste a link" into the initial form.)
There's also no real difference between a short meeting name plus password and a long meeting name, except that passwords tend not to be displayed on screen so it's even harder to find it to tell someone over the phone.
Also there's another big issue in how easy or convenient you make it for people from within your domain/company to join, versus outsiders. Half the company wants to make it harder for outsiders to join (for security), the other half (salespeople) want it to be easier.
The only solution, unfortunately, is educating users to understand the differences. Zoom already has most if not all the necessary options, even modes like "waiting room". But the same options will never work for every meeting. Whoever hosts a meeting needs to understand the options. There's just no substitute.
This is a really good point, and I actually sympathize with how difficult it is for Zoom to strike the right balance here.
If the only method of operation here were for people to invite others by copy/pasting a URL, and the invitees' only method of joining were to click on that link, then long UUIDs or such would be just fine.
But Zoom lets you dial in audio-only from a regular phone. You simply just cannot use "long random string" as an identifier if you're expecting someone to punch it into a telephone keypad. Even having an 9- to 11-digit meeting code plus say a 6-digit passcode would be a burden for some people, though it's really the only way to do that portion of it right.
Now, one thing I do not cut Zoom any slack for is having an API where you can request validity and status of any meeting ID, without any rate limits placed on it. That's Security 101 right there.
I don't know if botnets are still a thing, but it used to be that any rate-limits needed to be multiplied by 10k for even a modest attacker, as being able to query from 10k unique nodes was a fairly trivial problem by renting a botnet.
Meet has a 10-letters ID for meetings over HTTP and a 9-numbers ID (like zoom) for phoning in. It sounds complicated but in practice every Meet invitation has a single-tap phone link that dials the correct number and input the conference ID after a pause, all encoded in the link. It works flawlessly and so it doesn’t matter if that number is different from the concernce URL you click on a computer.
> Even having an 9- to 11-digit meeting code plus say a 6-digit passcode would be a burden for some people, though it's really the only way to do that portion of it right.
Strong disagree; people can handle 10-digit phone numbers, they can handle an order 10-digit meeting ID.
Who memorizes phone numbers anymore? Just because you can doesnt mean you will if theres an easier alternate version, and a lot of the public doesnt care about security enough to not use to easier option
Who said anything about memorize? There is no universal dial-in number -- for dialling into a conference, you're provided with a phone number and a meeting code. People already can manage that much. If the meeting code needs to be 15 digits in order to neuter "zoombombing", that's not much of a hurdle or burden.
People didn’t really memorize 10 numbers that often anyway. Most people whose numbers you knew would be in a small set of area codes, or just one, and even the next three might only have a couple possibilities for most useful numbers, unless you lived in a very dense area.
For the phone only route, it seems like you could still mostly automate it by going oldschool. Give the host an option to play the meeting code as a DTMF signal (or whatever) while the other person holds their phone near the mic.
Maybe I'm misunderstanding the use case then? I'm imagining something like:
A and B are on a phone call. A starts a video meeting. B goes to shortlink.dtmf or opens the app, which starts listening. A clicks "transmit room code" which goes over the existing phone connection. B's client hears the signal, decodes it, and gives them a link to join.
There is no reason why short meeting codes + 2-3 sec delay before joining + temporarily banning users who enter more than 10 invalid meeting codes in a row can't work.
There are ways to improve the security without putting on the clients shoulders. A 6 digit room code is fine if a person can only "war dial" 10 tries before being banned for an hour or so.
There's a really good reason why that wouldn't work. There's no reason why a war dialer can't create millions of users. The 2-3 second delay doesn't really accomplish much unless you limit their capacity to have requests pending.
On a large enough level, this would have to be treated the same way as spam traffic currently is. You'd never ban anything smaller than a /64 with IPv6. Getting DOS from a /48 or /56? Ban them, or do exponential back-off for all IPs in the block. It's not that hard for a botnet to get a few hundred thousand IPv4 addresses either, but we haven't taken that as a reason to just roll over. The difference between each IP sending you 1 request / sec and 10000 requests / sec is still profound.
Right, because in one case you'll see thousands of different meeting connection requests for different meetings from one IP, and in the other you'll see thousands of different meeting connection requests for different meetings from one IP.
What about a long, unique identifier for the baseline, and the ability to generate temporary, single (or `n`) use, short identifiers that can be used when speaking the id?
Clicking a long I'd link takes practically training, and entering a short ID would only require training the salespeople how to generate one (would should only be a few clicks tops).
This way, a conference is secure by default and easy for people to join by link, and is still easily accessable by code for when needed.
When I think about having two different solutions for two slightly different usecases, my mind always goes to Microsoft's decade-long battle to teach their users the difference between Standby and Hibernate.
There was very real value in the distinction to those who used it, but it proved so irresolvably confusing to the vast majority of users that eventually they pulled the plug and just gave the one Sleep option.
Educating users about technicalities they've probably never thought about is really hard. Doing so without an actual training session, just through interface, verges on impossible. And if Microsoft couldn't convince businesses to train their users, I doubt Zoom can.
> striking the right balance between ease of use and security is really hard.
Why not give more "Options"?
For example when generating conference id, provide an option to generate more random digits or hash codes. When installing provide an option to customize everything. Meanwhile provide a fast and fool-proof path for rest of users.
I really don't know that zoom has a lot or much at all, but I do know that the number of viable solutions to this could be taken off the table internally because they probably made tech debt commitments in their architecture during their scale up phase that prevents bolting on obvious fixes. I have a lot of sympathy for their position. They aren't evil or bad, but they could do a massive mea culpa PR coup on the level of the netflix culture deck if they did a case study retrospective about the effect of tech debt on scale at critical moments.
It's also a product management fail, where that lack of transparency on encryption is what a project-manager would pull, where a smarter product manager would have weighed the cost of losing their e2e-crypto compliance market.
I can also see why they have security issues because today, security people are on a much longer tailed skill distribution than they were 10y ago and it's hard to listen to most of us. Getting someone to approach it as, "ok, we get that a 9-digit key is literally your product selling UX advantage, let's see what else we can do" is exceedingly rare. Privacy has massive brand implications. Remember blackberry? They launched a new flagship tablet product while their CEO got into an issue with government surveillance and the story became about their risk in India and Asian markets and not whatever that product was called.
Zooms story is becoming about privacy problems too.
I think you overestimate the reliability of the alternatives.
Zoom focused all their early engineering muscle on reliability. When we build new products, we don't have infinite resources to attack every front simultaneously. We have finite resources to prove a concept, and we incur debt in just about every other dimension.
Now that everyone is using them (precisely because of reliability) the emphasis becomes other things - UX, security, etc.
Tech debt is what the 2nd generation of engineers gets to complain about after the 1st gen made the product succesful at something.
That last statement, I'm there with you on. Tech debt is necessary, it could even be renamed "tech leverage," because that's what a lot of it is.
My thing is that there are tons of potential ways to mitigate zoombombing, even incrementally, and that they haven't or chose not to indicates it's because there were cost barriers to doing it. It has the tech debt smell, and it's what I've seen in other orgs.
There is a basic information problem, where good people have it and bad people don't. You don't need cryptographicaly strong approaches, you just need speed bumps that impose costs on specific classes of attacker that disrupts their economy of scale. It's not a secrecy solution, it's an economic nudge.
Then there are ones with vs. without user interaction.
Without user interaction:
- rate limit join attempts so that you at minimum need proxies or a botnet to guess room names.
- do a simple entropy measurement of multiple attempts and rate limit anything that exhibits symmetry or monotonicity.
- add a "correct battery horse staple" style key to the url instead of or in addition to the 9 digit pin so the link is not easily guessable, but still has the mnemonic quality for people entering it manually.
- static personal room ID's only work with a passwd/token (not pin) whereas ephemeral ones can be chosen from a much larger search space. (yes, just add entropy)
- free sessions limited to 40mins or whatever should select from a name space large enough it will take a botnet to hit even one ephemeral session in the 40min timeframe.
- separate the invite link from the login link so that session owners can specify that the user needs to click from their email invite so it gets bound to the browser, and you zoom can set a token before redirecting them to the live session.
with user interaction:
- Obvious one would be a user PIN for ephemeral room IDs.
Rest of user interactive ones is exercise to the reader, as those are all solved problems.
The challenge is that they require keeping logical state at the application layer, which is specifically the kind of complexity you avoid in your scale-up architecture - and it burns you down the road.
> "Tech debt is what the 2nd generation of engineers gets to complain about after the 1st gen made the product succesful at something."
Strange and snarky comment for a "Chief Technical Officer". Software constantly evolves, it's a process of continuous refinement.
Zoom's past success may have been partially attributed to "1st gen engineers" hitting the jackpot. Zoom's fate right now rests on the ability of those "2nd generation engineers" to keep the show going.
Exactly! I've built plenty of rock-solid flawless products that never got any traction. I can assure you none of them were dissected on Hacker News. Personally I'd go for getting mass adoption followed by endless free security consulting provided by the internet while it's stuck at home.
It's not technical debt, because it was not a problem before.
More likely just a poorly designed system.
Security is always a game of 'staying ahead' - with a totally new userbase context, the security parameters have changed under their feet. So now they need to quickly adapt their product to the new context.
A vastly new usage context is going to create all sorts of stresses.
>It's not technical debt, because it was not a problem before.
You mean it wasn't problem before just because it wasn't being actively exploited before? A problem is a problem regardless if is as of yet undiscovered. Or do you mean it wasn't a problem because it wasn't preventing any forward progress on the product?
"A problem is a problem regardless if is as of yet undiscovered."
Instead of thinking that a product has 'some number of bugs, which when fixed, is perfect' - consider that there are maybe 'infinity' problems. In any given context, those problems are likely to cause differing levels of concern, in different ways, and that in different contexts they may be more likely discovered than not.
For example - Mac is generally considered to be a little bit more 'secure' (heavy quotations) than Windows, the party by design, but partly because of the likelihood of attacker exploits being discovered due to limited market share.
That considerably fewer people are attacking you is a legit thing, especially in light of the potential fallout: 3 weeks ago 'Zoom' was not a pop-culture term, a breach may not have made the big news. Now, everyone's talking about Zoom, so there's a problem and Anderson Cooper is talking about in CNN, the fallout is much worse.
In this 'new context,' the calculus has changed and the impetus to fix certain problems a to maybe actually be concerned about FB login will have changed.
Case and point: SpaceX's decision to not use Zoom made international headlines. This is a huge deal. A zillion IT staff around the world are at least going to read that article. 'Software made in China' they'll read. 'Wait, what?' They didn't know that, does it matter? 'My CEO saw it on the news last night and has asked for a security review, whereas we mightn't have done one otherwise' et. al..
Edit: MY CEO has not asked for a review, I'm making a hypothetical situation here I meant to be speaking in another voice.
I feel like security is a realm where that quote is demonstrably untrue. A "hole" in your system is exactly zero problem until the moment someone exploits it.
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.
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.
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.
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 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.)
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.
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.
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.
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 :(
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.
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.
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.
I feel a little bit sorry for the Zoom devs. All of a sudden there are a _lot_ of eyes on Zoom. Every design decision and mistake are under a big microscope, while also presumably having to deal with some major scaling.
It's a ~2k person company with a market cap of $34B. So the valuation is $17M per employee.
I don't feel sorry for them.
Also: this crisis is giving them vast amounts of marketing for free.
I'm based in Sweden. I was just vaguely aware of Zoom until a few days ago - now I suddenly hear of them all of the time from Late Night hosts on Youtube.
The developers are still people. Doesn't matter the size of the company, it's still a bunch of individuals who are likely suddenly dealing with a lot of stress and pressure that could never have been predicted, or have opportunity to scale up their engineering to meet.
I'm sure there are plenty of people who would be delighted to be in that situation. At the end of the day Zoom is looking to stay a run-away success - assuming eng is being compensated appropriately it's really one of the best problems one could have in a job.
I'd argue that if you're writing malicious privilege trampolines for operating systems, you could have very well predicted this would pop up and you get stressed out for it.
SpaceX seems big enough that they pay for a self-hosted meeting suite. I've worked at a couple places that use WebEx that is self-hosted. You can only access it via dialing the number (from any phone) or by being on the VPN to see the shared presentation. Trying to log into the public version of WebEx gives you an unknown user error. Someone could still wardial their way into the call but it would require getting the non-public phone number and guessing the meeting number AND possibly guessing a meeting password.
It's 1985 all over again: I'm in my bedroom running a ProDOS wardialer on my 300/1200 baud AppleModem; I have found zero computers, but it is fun watching the numbers flick past, hoping that I, too, can discover a WOPR and start global thermonuclear war.
"Shall we play a game of Global Thermonuclear War?"
"Sure!"
"Updating Steam client... It seems you're connecting from a new device! Please check the 2FA code sent to your email... Downloading more updates... Here are some popups about unrelated games... Please register an account with MS Game Live!... Downloading patches... [error in wopr.dll]"
>Each Zoom conference call is assigned a Meeting ID that consists of 9 to 11 digits.
8 char passwd and 16 digit credit cards came way before 1985.
Never mind, i have committed in memory our daily scrum 9 digit pin code :) Very convenient. And if somebody else were to dial in uninvited into our scrum ... well, it is at their own peril as it carries (especially for a person not hardened by a long tenure at a BigCo) the risk of brain damage, loss of ability to perceive reality as it is, spontaneous suicidal desire, etc.
Not a good idea to use 9 to 11 digit long IDs with no password requirement by default; they should have used at least 128-bit random ids, i.e. 21 character long base64-encoded strings.
This is likely to support dial-in over the telephone network.
I think "no password" is the bigger issue, because repeated attempts with incorrect passwords can be rate-limited. Zoom should be generating a random 6-digit password for each meeting by default.
There may be use cases for not having any password, but that should be explicitly opt-in and have a warning message to every participant that anyone can join and broadcast in this meeting.
i'm sure the reason for that is the UX.
the zoom had a reputation of "just works" and part of it was that is so easy to jump in to a meeting.
if now i have to manage access and so on, it would not be "it just works" like it was
The telephone dial-in option should've been separate - if the user chooses to enable it then they can fall back to shorter IDs, while meetings that don't need it (or where it doesn't make sense anyway - screen shares, presentations, etc) would use longer, more secure IDs.
As we've used it at work, the phone dial-in option is the backup plan -- useful when people can't set up their computer's microphone correctly, or lose Internet access for whatever reason.
The "just works" nature is why Zoom is popular. No one wants to have every meeting start with "Is Larry here? Oh, I think he's trying to dial in. I'm going to cancel this meeting and send out a new ID so he can dial in. Everyone watch for that so you can reconnect"
You could even include the option to get approval - pop up says "Mx. Caller ID is calling from 555.555.5555. Approve?" Obviously there's no way to get in through random dialing. And if you get a pile of requests, provide a way to filter incoming numbers and disable the calling ID as soon as everyone is in.
That's even assuming that anti-DOS protection on the phone line is impossible.
Even if the phone dial-in ID would be enabled by default (which isn't what I am suggesting), the extra latency and cost of brute forcing them over the phone network will make these attacks much harder.
I've always preferred conf systems with a call-me-at function better anyway. With most lines, sign in over phone is a horrible waiting game where one missed digit means sitting through instructions for another minute.
Could you not use a telephone intent, where the meeting ID is the suffix to the dial in number with commas for any necessary pauses? Skype for business meeting invites have this. Zoom might then support inviting mobile phone conference participants using SMS, containing the link (think weak 2FA).
The most secure computer is a non-networked standalone box sunk in concrete sunk hidden at the bottom of a deep sea trench. It is not, however, very usable.
Yes. If you're in a conference room and it's not a Zoom Room(tm), or has a Cisco system, or whatever, you have to use the conference phone. You might be able to tell the Zoom meeting host to call the conference phone and bring it into the meeting, but it'd be easier just to type the ID in (unless it was really 128 char, but then that'd give people a reason to buy new conference hardware I guess).
Also if you don't want to install the Zoom client, you can just dial in from your cell phone or desk phone.
When I did consulting, almost every meeting had at least one dial-in. If you didn't include a dial-in, you'd be guaranteed to either get a request to add one, or you'd get people who didn't show.
There was always:
1. someone who was on the road - a traveling consultant or someone in sales
2. a client or potential who called in because of the same, or because they don't sit at a computer all day and/or don't have a headset for their computer.
3. People in a conference room
4. a client who sucks at computers and dials in because they can't figure out how to install the latest version of CiscoGoToZoomMeetingWebEx.exe in IE8 on their macbook.
I've been working home since before the lockdown in my country. Since the lockdown, the number of online meetings that I have in a day has tripled. I think in about 2-3 meetings a day I have problems with microphone/hearing, and end up dialing in from my phone. This is normally for Skype for Business meetings.
The same tends to happen with a few colleagues ... Some anecdote.
Far greater than you would expect, I think. This is anecdotal, but we're an admittedly small company (~20-25 employees) and all of our interactions with other companies (clients) are either direct line-to-line or if we do a conference call, we all call in over the phone. Many of the companies who send us WebEx or join.me or Hangouts Meet or whatever invites only send the phone number even, not even bothering to give us a link (and if you go to the room manually in your browser, you're the only one actually connected via computer)
I call in for every meeting I can. My hearing is poor; the sound quality on the computer just isn't good enough for me. Then add in that my computer is heavily loaded, so it's ability to encode/decode sound is degraded.
I have a high quality desk phone on a land line (admittedly, VOIP from FIOS, but not via my computer) and I will fight tooth and nail to keep it.
All that being said, I'm comfortable typing in an arbitrary length password on my phone. All I ask is that it be formatted to make that easy (groups of 3-4 numbers with spaces).
Working in global research, 40% of our ROW (rest of world) sites and vendors use landline or cell pones to join our meetings, depends on their institutional security and IT settings.
My husband is a market researcher, and is now conducting market research over Zoom & other platforms. The first thing he does is have _everyone_ dial in. It's been a major help in reducing latency and dropped packets, which in turn has a majorly positive effect in getting stranger to be able to talk normally with each other. It helps prevent the "you go no you go" as latency allows people to unknowingly step over each other.
I would also enjoy being able to punch in '12345' as my password everywhere instead of launching LastPass all the time, but I accept that some conveniences aren't worth security consequences.
Good idea for this! But trickier for phone calling into a conversation. They could also just add 3 digits and a slight delay in their connection API, making it much harder to brute force, albeit only by a constant factor.
It's an incredibly simple thing to screw up. I wonder where else they use low entropy random strings. I wonder if their password reset functionality can be brute forced too. Another problem is where they put rate limiting as it seems probable based on this article there are holes.
In this case, relatively short numeric meeting ids allow users to dial in via plain old phone lines. If my meeting guests had to enter a UUID via their phone keypad, they would probably skip the meeting instead.
I mean, this is intentional. They even allow you to set your meeting ID to a well-known number, like your company's published phone number.
If you want to join the all-hands meetings of a company I used to work for, you only need to go their website and lookup their primary phone number. That's the Zoom meeting ID.
Not having password protection enabled seems like an unfortunate default, but I guess it's not that surprising given the number of "barriers" that Zoom attempts to bypass when you join a call.
I always wondered why teleconferencing systems don't incorporate a workflow where people connecting in need an approval from the organizer before actually entering the meeting.
And it’s a responsibility/pain for the facilitator when it’s on. Often they‘ll be caught up in the meeting and leave anyone who arrived 3 minutes late to spend the rest of the meeting waiting to be admitted.
I think a tool which is basically yet another webchat-solution but tries too push their omnipotent app onto you, no matter what, has some issues beyond security. All the "user"-friendly execution looks like some 2002 nigerian adware. I guess userfriendly is really easy if your app can never be closed (not sure about that), can't be uninstalled and you nag the user twice to actually really start that app before allowing to use a runtime under his/her control.
Oh the number of times I've been on 20+ people Zoom meetings which were interrupted after a minute by someone asking "Hold on folks, who is the phone-user who just dialed in?" Or whenever someone connected who had the wrong nick set (happened on Linux) and hadn't turned the video on yet, which basically meant the conversation stopped until the new arrival had identified himself.
They may decide there is nothing to fix. If you want to use a password you can.. but don't force it on the average user who would trade having no password with the potential of someone random joining.
I never understood "presenter will let you in" security. It's based on someone letting me in if they recognize my recorded name and that I work there? Surely that wont backfire in a world where everyone post every detail about every day of their life online. I mean who even uses LinkedIn anyway?
I know that WordPress doesn't have the greatest security record, but it seems unfair to judge an organization for using WP.
Many, many respectable businesses use WordPress for their brochureware or corporate blogs. In my experience, it's not a security nightmare if it's well maintained.
> I have had the same issue with the plugin. This was on a simple WooCommerce site with a few thousand products. Notice it incurred over $6,000 in fees.
> Amazon CloudFront Invalidations $6,485.76
> $0.000 per URL – first 1,000 URLs / month.1,000 URL$0.00
> $0.005 per URL – over 1,000 URLs / month.1,297,151 URL$6,485.76
After a user reporting a plugin costing his business over 6000 USD, months go by without proper attention to this issue. If there was good quality control, the plugin should have been pulled. It just shows how the ecosystem is not designed with robustness and security in mind.
But I agree, WP cannot be a proxy to judge how companies treat security. This just illustrates how bad WP itself is.
It's not really about entitlement. He's the one benefiting from people consuming his content, why not make it more accessible? All at the cost of some CSS rules.
As a consequence, I suspect Zoom's security is more likely than not to improve going forward... although it will surely take a long while. Security is Capital-H Hard.
Also, I cannot think of any other multi-video-conferencing solution that "just works" and has been as thoroughly stress-tested and attacked by bad actors in the wild at such a large scale. If Zoom does a decent-to-good job fixing all the security issues, it looks likely to continue to dominate its market.