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

151–160 of 226 posts

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

#151

Post by ablob »

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

Which alphabet did you take as a basis to reach 2^256 combinations?

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

#152

Post by ummonk »

noahtallen wrote: post #140
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 can easily rate-limit an authentication attempt, to make brute-forcing account access practically impossible, even for a relatively insecure passwords. How would you do that for the URLs? 5 requests to site.com/[256chars] which all 404 block your IP because you don't have a real link? I guess the security is relying on the fact that only a very a small percentage of the total possible links would be used? Though…

I don’t think you realize how exponentially large the possible combinations of 256 characters would be. In fact it doesn’t need to be anywhere near 256 characters. 64 hexadecimal characters would suffice.

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

#153

Post by [deleted] »

duskwuff wrote: post #55
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.

> 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. Not even close. 1024 bits is a really, really big address space. For the sake of argument and round numbers, let's say that there are 4.2 billion (2^32) valid URLs. That means that one out of every 2^992 randomly generated URLs is valid. Even if you guessed bi…

[deleted]

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

#154

Post by ummonk »

mbrumlow wrote: post #84
charleslmunger wrote: post #59

Earlier quoted context omitted.

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.

The same can almost as easily happen with user-submitted passwords.

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

#155

Post by r2b2 »

nightpool wrote: post #115
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…

The secret is still stored in the browser's history DB in this case, which may be unencrypted (I believe it is for Chrome on Windows last I checked). The cookie DB on the other hand I think is always encrypted using the OS's TPM so it's harder for malicious programs to crack

Yes, adding max-use counts and expiration dates to links can mitigate against some browser-history snooping. However, if your browser history is compromised you probably have an even bigger problem...

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

#156

Post by cj »

XorNot wrote: post #149
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,…

Worked for a company which ran into an S3 bucket naming collision when working with a client - turns out that both sides decided hyphenated-company-name was a good S3 bucket name (my company lost that race obviously). One of those little informative pieces where everytime I do AWS now all the bucket names are usually named - . If it's really meant to be private then you encrypt the project-name too and provide a scri…

What would encrypting the project name accomplish? Typically if you’re trying to secure a S3 bucket you’ll do that via bucket settings. Many years ago you had to jump through hoops to get things private, but these days there’s a big easy button to make a bucket inaccessible publicly.

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

#157

Post by andix »

erikerikson wrote: post #123
andix wrote: post #104

Earlier quoted context omitted.

Is there a feature of DNS I'm unaware of, that queries more than just the domain part? " rel="nofollow">https://example.com?token= should only lead to a DNS query with "example.com".

The problem isn't DNS in GP. DNS will happily supply the IP address for a CDN. The HTTP[S] request will thereafter be sent by the caller to the CDN (in the case of CloudFlare, Akamai, etc.) where it will be handled and potentially logged before the result is retrieved from the cache or the configured origin (i.e. backing server).

This sounds like a big security flaw in the system that uses access links. Secrets should not be logged (in most cases).

When opening a Dropbox/GoogleDocs/OneDrive link, I expect the application not to route them through potentially unsafe CDNs.

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

#158

Post by eddythompson80 »

blue_green_maps wrote: post #63
internetter wrote: post #31

Earlier quoted context omitted.

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.

That's not true. There is a JWT token in the url with about 5 minute expiration window.

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

#159

Post by bigiain »

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

Yeah - that's just red-flagging "interesting" urls to people running greyhat and blackhat crawlers.

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

#160

Post by lmm »

FrustratedMonky wrote: post #143
lmm wrote: post #139

Earlier quoted context omitted.

A plain URL is an open door not a closed one. Most websites are public and expected to be public.

Isn't that the point of the post? There are URL's that are out there 'as-if' public, but really should be private. And some people argue they should be treated as private, even if it is just a plain URL and public.

You can't blame the search engine for indexing plain URLs. Listing a closed-but-unlocked door is a bad analogy.
Post reply on HN