3 ms·
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
by 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 agoExactly. 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 agoMainly 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 agoHey, 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 agolong 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 agoNo, 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.