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

91–100 of 226 posts

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

#91

Post by marcosdumay »

AnotherGoodName wrote: post #9
scblock wrote: post #3

When it comes to the internet if something like this is not protected by anything more than a random string in a URL then they aren't really private. Same story with all the internet connected web cams you can find if you go looking. I thought we knew this already. Why doesn't the "Who is responsible" section even mention this?

Such links are very useful in an 'it's OK to have security match the use case' type of way. You don't need maximum security for everything. You just want a barrier to widespread sharing in some cases. As an example i hit 'create link share' on a photo in my photo gallery and send someone the link to that photo. I don't want them to have to enter a password. I want the link to show the photo. It's ok for the link to d…

The situation is greatly improved if you make the link short-lived and if you put the non-public data in a region of the URL that expects non-public data, like in the password, as in "https://anonymous:32_chars_hash@myphotolibrary.example.com/u...".

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

#92

Post by hiddencost »

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

No. In theory they are both totally insecure.

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

#93

Post by heipei »

godelski wrote: post #50

There's a clear UX problem here. If you submit a scan it doesn't tell you it is public. There can be a helpful fix: make clear that the scan is public! When submitting a scan it isn't clear, as the article shows. But you have the opportunity to also tell the user that it is public during the scan, which takes time. You also have the opportunity to tell them AFTER the scan is done. There should be a clear button to de…

Thanks for your feedback. We show the Submit button on our front page as "Public Scan" to indicate that the scan results will be public. Once the scan has finished it will also contain the same colored banner that says "Public Scan". On each scan result page there is a "Report" button which will immediately de-list the scan result without any interaction from our side. If you have any ideas on how to make the experience more explicit I would be happy to hear it!

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

#94

Post by layer8 »

loa_in_ wrote: post #79
layer8 wrote: post #72

Earlier quoted context omitted.

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 robots.txt in theory.

I didn’t think robots.txt would be applicable to URLs being copied around, but actually it might be, good point. Though again, collecting that robots.txt information could make it easier to search for such URLs.

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

#95

Post by runeb »

bombcar wrote: post #58
ttymck wrote: post #38

Zoom 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"?

If the password is randomized for each meeting, the URL link is not so bad, as the meeting will be dead and gone by the time the URL appears elsewhere. But in reality, nobody actually cares and just wants a "click to join" that doesn't require fumbling around - but the previous "just use the meeting ID" was too easily guessed.

Unless its a recurring meeting

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

#96

Post by layer8 »

internetter wrote: post #90
layer8 wrote: post #72

Earlier quoted context omitted.

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

How do you implement password-reset links otherwise? I mean, those should be short-lived, but still.

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

#97

Post by hawski »

victorbjorklund wrote: post #10

Can 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?

You can easily make a regex to filter out URLs. There is no universal regex (other than maybe costly LLM) to match the URL, the username and the password.

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

#99

Post by andersa »

layer8 wrote: post #96
internetter wrote: post #90

Earlier quoted context omitted.

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

How do you implement password-reset links otherwise? I mean, those should be short-lived, but still.

You could send the user a code that they must copy paste onto the page rather than sending them a link.
Post reply on HN