3 ms·

It's unconscionable they still hadn't implemented any sort of rate limiting. It should have been there from day one. For the protection of their customers, an

It's unconscionable they still hadn't implemented any sort of rate limiting. It should have been there from day one. For the protection of their customers, and their own infrastructure. After the string of "zoombombings", it should have been a top priority and received ongoing attention from their CEO until implemented. When I began using the platform, I assumed the randomly generated meeting numbers were buttressed by adequate account and connection attempt monitoring on their back end to make them "secure enough". After finding reason to suspect otherwise 5 months ago, I contacted Zoom about it twice and never received a response (from what I can tell support is overwhelmed and tickets even for serious issues like security breaches and billing errors can take months to hit human eyes). The password-in-the-link approach felt to me like security theatre. Yes, it adds value, but really doesn't amount to anything more than a bit of additional URL obfuscation (particularly given the length and character limitations), unless you're distributing passwords separately - which can be onerous for attendees. Hats off to this researcher for forcing the issue and finally incentivizing the company to work on cleaning up their act. But it makes me worry about where else in their platform they took shortcuts. They've really nailed the "frictionless" part (and I commend them for that) but I'm convinced you can achieve a friendly user experience while still maintaining a basic level of security.

varenc 6y ago
Aren’t secret unguessable URLs used all the time to secure content? See gdocs, Dropbox shared files, etc. Of course the password shouldn’t be 6 digits...but as long as the URL space is unsearchably massive, say 256 bits, and there’s some basic rate limiting, embedding a “password” or random token in a URL seems an acceptable way to frictionlessly share private content?
- rkagerer 6y ago
  Exactly. The Zoom links don't tend to have a large search space by comparison, and AFAIK all the services you mentioned use connection throttling and other mechanisms to detect and stop abuse before it goes rampant. Appending a passcode is little different than if they were to just use longer meeting numbers in the first place (but with sometimes-worse entropy e.g. when the user changes it to "123456"). So they bought a few more bits (evidently still not enough to beat the bad guys) at the price of extra user hassle. If they were more aggressive on the server side, they could probably get away just fine with the smaller, more convenient links and wouldn't need to push users so hard to turn on "frictiony" features like waiting rooms. Private links work great as long as the team providing them understands the tradeoffs and appropriately mitigates risks. Zoom isn't the first service to be brute-forced [1], and there are more subtle ways for links to leak [2] (e.g. I think someone's tax returns once wound up on Google after the secret Dropbox URL was passed in a referrer header). [1] https://www.theregister.com/2011/05/08/file_hosting_sites_under_attack/ https://www.theregister.com/2011/05/08/file_hosting_sites_un... [2] https://softwareengineering.stackexchange.com/a/325821/79139 https://softwareengineering.stackexchange.com/a/325821/79139
  - varenc 6y ago
    Mainly just trying to say that not all secret URL approaches are security theatre. Though Zoom's approach definitely is! Totally agree that in the long term secret URLs can end up being a risk. They're so easily leaked and URLs themselves often aren't treated securely. I'm sure many GSuite/Dropbox corp admins forbid them. Though for many personal situations IMHO a secret URL is a perfect fit. Hah, that Dropbox referrer issue you mention brings back memories! I recall the annoying challenges involved in securing that in a way that still let users view raw files/previews in browser without just forcing the content to be downloaded.(And this was in a world before the Referrer-Policy header)
    - rkagerer 6y ago
      Hey, you didn't work there by any chance did you? I really loved the old "Public" folder and agree those direct-to-raw-file links were super convenient (when used appropriately of course!)
      - varenc 6y ago
        long ago :-) You can still get links directly to raw files...mostly! Just use the very under-advertised "?raw=1" param on a shared link. For example: https://www.dropbox.com/s/9i4696v9kqewoyw/Screenshot%202020-07-29%2017.55.12.png?raw=1 https://www.dropbox.com/s/9i4696v9kqewoyw/Screenshot%202020-... (does a redirect, and won't work for HTML. And some content like PDFs are served from locked down temporary URLs so that that referrer is useless of course)
- SahAssar 6y ago
  No, URLs are not secret or secure, at best they are hidden. A proper secret is something that you can only give consciously, URLs are often shared without intent (via screensharing, screenshots, (often unencrypted) emails, server/proxy logs, etc). Many services like the ones you quote do allow sharing via URLs for ease of use but should also have a option to turn off auth-in-url style authentication for things that are sensitive. It's okay for things that have a low value but need to be shared easily, but should not be considered secure.

varenc 6y ago

Aren’t secret unguessable URLs used all the time to secure content? See gdocs, Dropbox shared files, etc. Of course the password shouldn’t be 6 digits...but as long as the URL space is unsearchably massive, say 256 bits, and there’s some basic rate limiting, embedding a “password” or random token in a URL seems an acceptable way to frictionlessly share private content?

rkagerer 6y ago
Exactly. The Zoom links don't tend to have a large search space by comparison, and AFAIK all the services you mentioned use connection throttling and other mechanisms to detect and stop abuse before it goes rampant. Appending a passcode is little different than if they were to just use longer meeting numbers in the first place (but with sometimes-worse entropy e.g. when the user changes it to "123456"). So they bought a few more bits (evidently still not enough to beat the bad guys) at the price of extra user hassle. If they were more aggressive on the server side, they could probably get away just fine with the smaller, more convenient links and wouldn't need to push users so hard to turn on "frictiony" features like waiting rooms. Private links work great as long as the team providing them understands the tradeoffs and appropriately mitigates risks. Zoom isn't the first service to be brute-forced [1], and there are more subtle ways for links to leak [2] (e.g. I think someone's tax returns once wound up on Google after the secret Dropbox URL was passed in a referrer header). [1] https://www.theregister.com/2011/05/08/file_hosting_sites_under_attack/ https://www.theregister.com/2011/05/08/file_hosting_sites_un... [2] https://softwareengineering.stackexchange.com/a/325821/79139 https://softwareengineering.stackexchange.com/a/325821/79139
- varenc 6y ago
  Mainly just trying to say that not all secret URL approaches are security theatre. Though Zoom's approach definitely is! Totally agree that in the long term secret URLs can end up being a risk. They're so easily leaked and URLs themselves often aren't treated securely. I'm sure many GSuite/Dropbox corp admins forbid them. Though for many personal situations IMHO a secret URL is a perfect fit. Hah, that Dropbox referrer issue you mention brings back memories! I recall the annoying challenges involved in securing that in a way that still let users view raw files/previews in browser without just forcing the content to be downloaded.(And this was in a world before the Referrer-Policy header)
  - rkagerer 6y ago
    Hey, you didn't work there by any chance did you? I really loved the old "Public" folder and agree those direct-to-raw-file links were super convenient (when used appropriately of course!)
    - varenc 6y ago
      long ago :-) You can still get links directly to raw files...mostly! Just use the very under-advertised "?raw=1" param on a shared link. For example: https://www.dropbox.com/s/9i4696v9kqewoyw/Screenshot%202020-07-29%2017.55.12.png?raw=1 https://www.dropbox.com/s/9i4696v9kqewoyw/Screenshot%202020-... (does a redirect, and won't work for HTML. And some content like PDFs are served from locked down temporary URLs so that that referrer is useless of course)
SahAssar 6y ago
No, URLs are not secret or secure, at best they are hidden. A proper secret is something that you can only give consciously, URLs are often shared without intent (via screensharing, screenshots, (often unencrypted) emails, server/proxy logs, etc). Many services like the ones you quote do allow sharing via URLs for ease of use but should also have a option to turn off auth-in-url style authentication for things that are sensitive. It's okay for things that have a low value but need to be shared easily, but should not be considered secure.