All media/photos you upload to a private airtable.com app are public links. No authentication required if you know the url.
This is actually fairly common for apps using CDNs – not just airtable. I agree it's potentially problematic
You cannot simply publicly access private secure links, can you?
31–40 of 226 posts
Re: You cannot simply publicly access private secure links, can you?
#32Earlier quoted context omitted.
There's functionally no difference between a private link and a link protected by a username and password or an api key, as long as the key space is large enough.
You can’t revoke an individual user’s access to a hard to guess link.
You can if it's one link per user
Re: You cannot simply publicly access private secure links, can you?
#33I've always been a bit suspicious of infinite-use "private" links. It's just security thru obscurity. At least when you share a Google doc or something there's an option that explicitly says "anyone with the URL can access this". Any systems I've built that need this type of thing have used Signed URLs with a short lifetime - usually only a few minutes. And the URLs are generally an implementation detail that's not d…
There's functionally no difference between a private link and a link protected by a username and password or an api key, as long as the key space is large enough.
I mean, there's a functional difference if your email client will try to protect you by submitting the URL to a public database. Which is incredible and mind-boggling, but also apparently the world we live in.
Re: You cannot simply publicly access private secure links, can you?
#34The fundamental issue is that links without any form of access control are presumed private, simply because there is no public index of the available identifiers. Just last month, a story with a premise of discovering AWS account ids via buckets[0] did quite well on HN. The consensus established in the comments is that if you are relying on your account identifier being private as some form of security by obscurity,…
Bit of a tangent, but I was recently advised by a consultant that pushing private Nix closures to a publicly-accessible S3 bucket was fine since each NAR file has a giant hash in the name. I didn't feel comfortable with it so we ended up going a different route, but I've continued to think about that since how different is it really to have the "secret" be in the URL vs in a token you submit as part of the request for the URL?
And I think for me it comes down to the fact that the tokens can be issued on a per-customer basis, and access logs can be monitored to watch for suspicious behaviour and revoke accordingly.
Also, as others have mentioned, there's just a different mindset around how much it matters that the list of names of files be kept a secret. On the scale of things Amazon might randomly screw up, accidentally listing the filenames sitting in your public bucket sounds pretty low on the priority list since 99% of their users wouldn't care.
Re: You cannot simply publicly access private secure links, can you?
#35Earlier quoted context omitted.
You can’t revoke an individual user’s access to a hard to guess link.
You can if it's one link per user
Lots of platforms I've used with these public share links don't really support multiple share links, and if they do the management of it is pretty miserable. Clicking share multiple times just gives the same link.
Re: You cannot simply publicly access private secure links, can you?
#36Earlier quoted context omitted.
You can’t revoke an individual user’s access to a hard to guess link.
You can if it's one link per user
True but if you’re generating one link per user, at what point do you lift up your head and wonder if it wouldn’t be easier to just use authentication?
Re: You cannot simply publicly access private secure links, can you?
#37Can someone smarter explain to me what is different between? 1) domain.com/login user: John password: 5 char random password 2) domain.com/12 char random url If we assume both either have the same bruteforce/rate limiting protection (or none at all). Why is 1 more safe than 2?
The difference is that people (and software that people write) often treat URLs differently than a password field. 12 characters might take X amount of time to brute force, but if you already have the 12 characters, that time drops to zero.
Re: You cannot simply publicly access private secure links, can you?
#38Zoom meeting links often have the password appended as a query parameter. Is this link a "private secure" link? Is the link without the password "private secure"?
Re: You cannot simply publicly access private secure links, can you?
#39Off topic: but that links to cloudflare radar which apparently mines data from 1.1.1.1. I was under the impression that 1.1.1.1 did not use user data for any purposes?
CF doesn't sell it or use it for marketing, but the entire way they even got the addresses was because APNIC wanted to study the garbage traffic to 1.1.1.1.
Re: You cannot simply publicly access private secure links, can you?
#40The fundamental issue is that links without any form of access control are presumed private, simply because there is no public index of the available identifiers. Just last month, a story with a premise of discovering AWS account ids via buckets[0] did quite well on HN. The consensus established in the comments is that if you are relying on your account identifier being private as some form of security by obscurity,…
Bit of a tangent, but I was recently advised by a consultant that pushing private Nix closures to a publicly-accessible S3 bucket was fine since each NAR file has a giant hash in the name. I didn't feel comfortable with it so we ended up going a different route, but I've continued to think about that since how different is it really to have the "secret" be in the URL vs in a token you submit as part of the request fo…
> how different is it really to have the "secret" be in the URL vs in a token you submit as part of the request for the URL?
I'm not sure I grok this. Do you mean, for example, sending a token in the POST body, or as a cookie / other header?
One disadvantage to having a secret in the URL, versus in a header or body, is that it can appear in web service logs, unless you use a URI fragment. Even then, the URL is visible to the user, and will live in their history and URL bar - from which they may copy and paste it elsewhere.