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

81–90 of 226 posts

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

#81

Post by kube-system »

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

Earlier quoted context omitted.

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.

https://1.1.1.1/dns/

> We will never sell your data or use it to target ads.

https://developers.cloudflare.com/1.1.1.1/privacy/public-dns...

> Cloudflare will not sell or share Public Resolver users’ personal data with third parties or use personal data from the Public Resolver to target any user with advertisements.

There's a lot of transparency on that page in particular, down to the lists of the fields in the logs.

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

#82

Post by eknkc »

masom wrote: post #49
ta1243 wrote: post #4

Earlier quoted context omitted.

The problem is links leak. In theory a 256 hex-character link (so 1024 bits) is near infinitely more secure than a 32 character username and 32 character password, as to guess it https://site.com/[256chars] As there's 2^1024 combinations. You'd never brute force it vs https://site,com/[32chars] with a password of [32chars] As there's 2^256 combinations. Again you can't brute force it, but it's more likely than the 2^…

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.

We call 128 bit random data “universally” unique ids. 1024 bits won’t ever get close to returning any random hits.

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

#83

Post by koito17 »

fiddlerwoaroof wrote: post #66
makapuf wrote: post #51

Earlier quoted context omitted.

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

To play devil's advocate, people discourage "security by obscurity" but not "security with obscurity". That is to say, secrets or "obscurity" as part of a layer in your overall security model isn't what gets contested, it's solely relying on obscure information staying obscure that gets contested.

e.g. configuring an sshd accepting password auth and unlimited retries to listen on a non-22 port is "security by obscurity". configuring an sshd to disallow root logins, disallow password authentication, only accept connections from a subset of "trustworthy" IP addresses, and listen on a non-22 port, is "security with obscurity"

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

#84

Post by mbrumlow »

charleslmunger wrote: post #59
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.

I'm not sure your math checks out. With 1024 bits of entropy and, say, 1 trillion valid links, your chances of any one link being valid are 1/2^984 So test a million links - your probability of finding a real one is (1-1/2^984)^1000000. That's around 1/10^291 chance of hitting a valid URL with a million tries. Even if you avoid ever checking the same URL twice it will still take you an impractical amount of time.

All this is fine and dandy until your link shows up in a log at /logs.

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

#85

Post by vin10 »

albert_e wrote: post #68
knome wrote: post #53

Earlier quoted context omitted.

>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 li…

You are right about short expiry times but another catch here is that if pre-signed URLs are being leaked in an automated fashion, these services also keep the downloaded content from these URLs around. I found various such examples where links no longer work, but PDFs downloaded from pre-signed URLs were still stored by scanning services.

From https://urlscan.io/blog/2022/07/11/urlscan-pro-product-updat...

> In the process of scanning websites, urlscan.io will sometimes encounter file downloads triggered by the website. If we are able to successfully download the file, we will store it, hash it and make it available for downloading by our customers.

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

#86

Post by OtherShrezzing »

empath-nirvana wrote: post #21
QuercusMax wrote: post #19

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

There's at least one critical functional difference: The URL stays in the browser's history after it's been visited.

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

#87

Post by [deleted] »

victorbjorklund wrote: post #16
amanda99 wrote: post #12

Earlier quoted context omitted.

Two things: 1. "Password" is a magic word that makes people less likely to just paste it into anything. 2. Username + passwords are two separate pieces of information that are not normally copy-pasted at the same time or have a canonical way of being stored next to each other.

1) Make sense. 2) Not sure about that. If someone shares their password with someone else they probably share both the username/email and the password

[deleted]

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

#88

Post by Y_Y »

ta1243 wrote: post #4
internetter wrote: post #2

The 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,…

The problem is links leak. In theory a 256 hex-character link (so 1024 bits) is near infinitely more secure than a 32 character username and 32 character password, as to guess it https://site.com/[256chars] As there's 2^1024 combinations. You'd never brute force it vs https://site,com/[32chars] with a password of [32chars] As there's 2^256 combinations. Again you can't brute force it, but it's more likely than the 2^…

> site-comma-com

Did you do that just to upset me?

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

#89

Post by klabb3 »

r2b2 wrote: post #56

To create private shareable links, store the private part in the hash of the URL. The hash is not transmitted in DNS queries or HTTP requests. Ex. When links.com?token= is visited, that link will be transmitted and potentially saved (search parameters included) by intermediaries like Cloud Flare. Ex. When links.com# is visited, the hash portion will not leave the browser. Note: It's often nice to work with data in th…

Thanks, finally some thoughts about how to solve the issue. In particular, email based login/account reset is the main important use case I can think of.

Do bots that follow links in emails (for whatever reason) execute JS? Is there a risk they activate the thing with a JS induced POST?

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

#90

Post by internetter »

layer8 wrote: post #72
internetter wrote: post #5

Earlier quoted context omitted.

Dorking is the technique of using public search engine indexes to uncover information that is presumed to be private. It has been used to uncover webcams, credit card numbers, confidential documents, and even spies. The problem is the website administers who are encoding authentication tokens into URL state, not the naive crawlers that find them.

I wonder if there would be a way to tag such URLs in a machine-recognizable, but not text-searchable way. (E.g. take every fifth byte in the URL from after the authority part, and have those bytes be a particular form of hash of the remaining bytes.) Meaning that crawlers and tools in TFA would have a standardized way to recognize when a URL is meant to be private, and thus could filter them out from public searches.…

We already have a solution to this. It’s called not including authentication information within URLs

Even if search engines knew to include it, would every insecure place a user put a link know it? Bad actors with their own indexes certainly wouldn’t care

Post reply on HN