Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

You cannot simply publicly access private secure links, can you?

vin01.github.io

Post reply on HN
Print view View original

61–70 of 226 posts

Re: You cannot simply publicly access private secure links, can you?

#61

Post by dylanowen »

knome wrote: post #53
shkkmo wrote: post #14

Earlier quoted context omitted.

It can be OK to put authentication tokens in urls, but those tokens need to (at a bare minimum) have short expirations.

>It can be OK to put authentication tokens in urls When would this ever be necessary? URL session tokens have been a bad idea ever since they first appeared. The only things even near to auth tokens I can reasonably see stuffed into a URL are password reset and email confirmation tokens sent to email for one time short expiration use. Outside of that, I don't see any reason for it.

They're useful for images when you can't use cookies and want the client to easily be able to embed them.

Re: You cannot simply publicly access private secure links, can you?

#62

Post by rpigab »

Links that are not part of a fast redirect loop will be copied and pasted to be shared because that's what URLs are for, they're universal, they facilitate access to a resource available on a protocol.

Access control on anything that is not short-lived must be done outside of the url.

When you share links on any channel that is not e2ee, the first agent to access that url is not the person you're sending it to, it is the channel's service, it can be legitimate like Bitwarden looking for favicons to enhance UX, or malicious like FB Messenger crawler that wants to know more about what you are sharing in private messages.

Tools like these scanners won't get better UX, because if you explicitly tell users that the scans are public, some of them will think twice about using the service, and this is bad for business, wether they're using it for free or paying a pro license.

Re: You cannot simply publicly access private secure links, can you?

#63

Post by blue_green_maps »

internetter wrote: post #31
sbr464 wrote: post #28

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

Yes, this is the case for images uploaded through GitHub comments, I think.

Re: You cannot simply publicly access private secure links, can you?

#64

Post by saagarjha »

blueflow wrote: post #52
masom wrote: post #49

Earlier quoted context omitted.

You won't find a specific link, but at some point if you generate millions of urls the 1024 bits will start to return values pretty quick through bruteforce. The one link won't be found quickly, but a bunch of links will. You just need to fetch all possibilities and you'll get data.

1024 bits seems a bit too much for the birthday problem to be a thing. I looked at [1] to do the calculation but (2^1024)! is a number too large for any of my tools. If someone has a math shortcut to test this idea properly... [1] https://en.wikipedia.org/wiki/Birthday_problem#Calculating_t...

Stirling’s approximation?

Re: You cannot simply publicly access private secure links, can you?

#65

Post by ironmagma »

nkrisc wrote: post #42
empath-nirvana wrote: post #21

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

There’s a big difference. The latter requires information not contained in the URL to access the information.

That's not a fundamental difference but a difference of convention. A lot of us have been in the convention long enough that it seems like a fundamental.

Re: You cannot simply publicly access private secure links, can you?

#66

Post by fiddlerwoaroof »

makapuf wrote: post #51
overstay8930 wrote: post #18

Breaking news: Security by obscurity isn't actually security

Well, I like my password/ssh private key to be kept in obscurity.

Yeah, I’ve always hated this saying because all security involves something that is kept secret, or “obscure”. Also, obscurity is a valid element of a defense in depth strategy

Re: You cannot simply publicly access private secure links, can you?

#68

Post by albert_e »

knome wrote: post #53
shkkmo wrote: post #14

Earlier quoted context omitted.

It can be OK to put authentication tokens in urls, but those tokens need to (at a bare minimum) have short expirations.

>It can be OK to put authentication tokens in urls When would this ever be necessary? URL session tokens have been a bad idea ever since they first appeared. The only things even near to auth tokens I can reasonably see stuffed into a URL are password reset and email confirmation tokens sent to email for one time short expiration use. Outside of that, I don't see any reason for it.

"presigned" URLs[1] are a pretty standard and recommended way of providing users access to upload/download content to Amazon S3 buckets without needing other forms of authentication like IAM credential pair, or STS token, etc

Web Applications do utilize this pattern very frequently

But as noted i previous comment these do have short expiry times (configurable) so that there is no permanent or long-term risk on the lines of the OP article

[1]: https://docs.aws.amazon.com/AmazonS3/latest/userguide/using-...

Re: You cannot simply publicly access private secure links, can you?

#69

Post by amanda99 »

kube-system wrote: post #39
amanda99 wrote: post #13

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

> CF doesn't sell it or use it for marketing

Any source for this? Do you work there? I checked their docs and they say they don't "mine user data", so I wouldn't trust anything they say, at least outside legal documents.

Re: You cannot simply publicly access private secure links, can you?

#70

Post by deathanatos »

nkrisc wrote: post #42
empath-nirvana wrote: post #21

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

There’s a big difference. The latter requires information not contained in the URL to access the information.

> Here's the URL to the thing: https://example.com/a/url?secret=hunter2

This is indexable by search engines.

> Here's the URL to the thing: https://example.com/a/url and the password is "hunter2".

This is indexable by search engines.

Yes, the latter is marginally harder, but you're still leaning on security through obscurity, here.

The number of times I have had "we need to securely transmit this data!" end with exactly or something equivalent to emailing an encrypted ZIP with the password in the body of the email (or sometimes, some other insecure channel…) …

Post reply on HN