‘War Dialing’ tool exposes Zoom’s password problems | Hacker News Reader

‘War Dialing’ tool exposes Zoom’s password problems

krebsonsecurity.com

585 pointsfeross234 comments

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.

>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.

Discussions: https://news.ycombinator.com/item?id=22757697

https://news.ycombinator.com/item?id=22756730

Pro: A worldwide, motivated, unpaid volunteer team is doing their thorough security audit, privacy review and QA testing for them.

Con: After the product was released :)

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.

Fun fact - perhaps not widely known and perhaps why it shares a similar philosophy as Webex:

Zoom was founded in 2011 by Eric Yuan, a lead engineer from Cisco Systems and its collaboration business unit WebEx.[1] [1] https://en.wikipedia.org/wiki/Zoom_Video_Communications#Hist...

I've always wondered about spinoff startups like this from larger companies: aren't there usually non competes that would prevent them starting them?

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.

They're generally not enforceable in California, provided you're not making use of any protected IP or what not.

https://casetext.com/statute/california-codes/california-bus...

IMO, when it comes to security, the fact that other people have made the same mistake makes a design flaw more egregious, not less.

That is absolutely not an information security norm. Most security mistakes fall into common patterns.

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.

As with most things, its a trade off.

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.

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.

Zoom in fact also allows you to enable a "waiting room" for all meetings owned by your account.

It's not always ideal though. I've organized meetings with 10+ people, want able to attend the meeting and now nobody can join the session.

I'm not sure about this, but there is a way to make someone a co-host who could then presumably make those decisions?

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.

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.

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 was by far the worst of all the ones we tried.

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...

Neither does Webex's browser version - even though I give it permissions, audio requires Webex to call me.

Latest Safari/macOS.

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.

This is likely why they really push you to install the app, rather than use the browser version.

They have a lot more ability to ensure it works when it's their own binary. When you're relying on a bunch of browser functions, it's way harder.

The browser version is a last resort.

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.

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.

> Security is Capital-H Hard.

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

>horrendous security flaws

You’re kidding... right?

Yes now Google meet uses random alphanumeric meeting ids this helps for sure you needed to find the.balance between security and accessibility.

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.

Ok. This was way too funny. Linking to a wordpress blog about their focus on fixing security bugs.

Jitsi "just work" and is much secure (https://meet.jit.si/)

>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.

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.

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.

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.

DTMF signal played over what exactly? The phone option is for when you aren't at a computer (driving, conference, etc..).

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.

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.

You are assuming a cell phone that calls in. But lots of people dial in manually from an actual telephone.

Do you have any statistics on "actual phone" usage? I'd imagine it's very low these days.

> 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

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.

If you have the same meeting every day, you will start memorising the numbers naturally.

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.

All good points.

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.

s/users/ips/

With IPv6, I can assign myself a gazillion perfectly routable unique public IPs.

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.

Yes, that's brilliant. That should work well when most of your customers are behind corporate NAT access points.

Thanks. Yeah, your customers aren't the ones who are going to get IP banned by wardialing.

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.

You then have a DDOS problem

> 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.

This is what technical debt gets you.

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.

PMs need to be smarter about this.

> This is what technical debt gets you.

Becoming one of the top names in video conferencing and displacing dozens of established players virtually overnight? Sign me up.

> Becoming one of the top names in video conferencing and displacing dozens of established players virtually overnight? Sign me up.

What!? That's small thinking. You could be so many greater things than that if you're willing to compromise peoples security and personal information.

I know you're being sarcastic but there are a ton of companies that have a terrible security track record and yet are quite large...

so that makes it right?

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.

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.

Do any of those potential ways impact on the ease of use of Zoom? Do they make it harder to join a meeting?

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.

- Next obvious would be to choose a real security protocol and key management scheme (http://www.lsv.fr/Software/spore/index.html)

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.

> My thing is that there are tons of potential ways to mitigate zoombombing

Someone call the feds quickly, that sounds like a very serious crime.

> "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.

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.

Have a look at the current outstanding exploits on all the software you use, even 'name brand software' from FAANGS. It's scary.

Mostly all we can do is triage and it mostly works.

But I'm all for a more sound approach.

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.

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.

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.

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.

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.

Yeah.. no.

Only on HN could these winners become "victims".

> Only on HN could these winners become "victims".

Maybe because the users on here have an unique perspective on developers / development?

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.

Zoom is pretty lucky to get so much free security scrutiny. I hope they make the most of it and fix all of these issues..

Three of the big issues reported in the past week have also been corrected in the past week, so they’re certainly trying.

> "KrebsOnSecurity is not naming the companies involved"

This chart suggests that one of the companies they found was an aerospace company: https://krebsonsecurity.com/wp-content/uploads/2020/04/zward...

I wonder if this is related to the news yesterday that SpaceX has banned the use of Zoom.

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.

Yeah but this time, it’s an easy as guessing a world leaders zoom meeting, and tricking them into believing something preposterous

I remember a Montreal morning show doing this via phone and tricking a few world leaders. Hopefully some funny things come out of this.

Hopefully we don't have any unfunny things come out of this.

Modern Version: "Shall we play a game?" "Love to" "‼To play Global Thermonuclear War, you must first update your flash player. Click here‼️"

An even more modern version:

"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]"

Those red exclamation points have convinced me this is legitimate.

Supposedly Captain Crunch got on the phone with Nixon, so it isn't that far off.

>It's 1985 all over again

i think it is even earlier than that:

>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.

Most Unix systems had 8 character password limits well into the 90's (a limitation of the original DES-based crypt.)

Shout outs to l0pht and cdc, but not to Minor Threat[1] ?

[1] https://en.wikipedia.org/wiki/Chris_Lamprecht

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.

How would that support phone dial-ins? (Yes, lots of people still dial into meetings all the time.)

I enjoy being able to dial meeting IDs into my phone

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.

That's a fine compromise for internal teams.

For those working with current or potential customers remotely, you have to use a solution that is convenient or you don't make money.

Yeah but then it sucks for people calling in to have to punch in a 21+ character long meeting ID

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).

Example: tel://18005551212,,<meeting_id>#

That's not helpful when you have to punch it into a conference room speakerphone.

I did once put together a hack that would scrape the meeting ID from the Zoom UI and emit the touchtones from my laptop to dial in.

There is always a trade off between security and usability. I like your hack though, any chance you'd put it on Github?

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.

I haven't used it in a while, so I wouldn't be surprised if the Zoom bit is broken, but here it is:

https://gist.github.com/micahbf/91a295016f4472b47acfe317d714...

> Yeah but then it sucks for people calling in to have to punch in a 21+ character long meeting ID

I may be out of touch with the average biz-guy, but how many people are realistically calling in manually, over traditional phone-lines these days?

Is it really a significant percentage?

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)

Most of my zoom meetings have at least 20% dial-ins.

From landlines?

Don't forget soft phones.

usually cell phones, but no one wants to install the app

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.

Smart phones can dial a long code in software. Only dumb phones and landlines can't

Some smartphones, using some applications, and some input devices, can dial some long codes.

Jim from sales who is dialing in from his company's oddball calendar app over Bluetooth on the infotainment system in his rental car probably can't.

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.

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.

My place of work didn't have a soft-phone connection to our computers until this COVID-19 mess started. I imagine we weren't alone.

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 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).

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.

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.

which means all you gotta do is war dial the phone network...

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.

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"

The second ID can be generated in addition to the first, primary ID.

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.

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.

What's worse, entering a 21-character meeting ID on the phone, or entering an 11-character meeting ID plus a 10-character password?

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.

Real engineering is about compromises.

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.

That actually makes sense I didn't know you could dial in with a phone.

Every time I read about a Zoom "screwup" I see a feature that's UX centric. It's pretty cool tbh.

> Every time I read about a Zoom "screwup" I see a feature that's UX centric. It's pretty cool tbh.

Like dialing Facebook even if you're not a Facebook user (https://news.ycombinator.com/item?id=22693792)?

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.

Or my personal favorite for anything you show to a user:

https://www.crockford.com/base32.html

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.

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

In this context, a password is the same as an id.

There's never a reason to share the id without the password.

They are as of the update to my client this morning.

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.

Most do, but in Zoom it’s off by default. (Waiting room)

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.

Maybe naive, but why doesnt Zooom do something like SSO? Why is the identity of attendees not validated? Wouldn't that solve the problem?

Then they'd need to charge extra for the SSO tax ;)

https://sso.tax

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.

Chatroulette Zoom Edition

Why doesn't Google Hangouts/Meet have this issue?

Hangouts has this issue as well.

zoom is not showing real effort to hunker down on privacy. and can feel its consequences as its stock is already down by 8% over the week

How hard is this for them to fix?

Not hard, everyone needs to password-protect their meetings.

Why?

Generating a random 6-digit passcode for each meeting by default? Not hard at all.

Rate-limiting incorrect password attempts could take a bit longer to implement, but still not a particularly difficult problem to solve.

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?

You can also require users to be authenticated (through SSO or other mechanism) before they log in, which could defeat some impersonation attempts.

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.

If you want to keep it private use a password.

wow! haven't heard that term in a while.

we used to do this looking for modems to dial into.

I remember WarDriving - driving around to pick up WiFi SSIDs. That was about 20 years ago.

[deleted]

That wasn't really arbitrary code execution.

https://unicorn.computer/zoom-wins-malware-of-the-year-march...

Hey... I created a tool that can hack Zoom meetings faster.... let me tip Brian Krebs about it and advertise it to the world.

I don't understand why this article exists. It's like a beacon for all the bored skidz now.

Reply on news.ycombinator.com