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

121–130 of 226 posts

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

#121

Post by nightpool »

voiper1 wrote: post #75
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…

>At least when you share a Google doc or something there's an option that explicitly says "anyone with the URL can access this". Unfortunately, it's based on the document ID, so you can't re-enable access with a new URL.

Not true, as you may have heard they closed this loophole in 2021 by adding a "resource key" (that can be rotated) to every shared URL: https://9to5google.com/2021/07/28/google-drive-security-upda....

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

#122

Post by nightpool »

amanda99 wrote: post #20
victorbjorklund wrote: post #16

Earlier quoted context omitted.

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

Yes, people share usernames and passwords, but there's no single canonical string, like "username=amanda99&password=hithere". For example most of the time when I share user/pass combos, they are in separate messages on Signal. You type them into two different boxes, so you normally copy the username, then the password in separate actions.

I mean, for HTTP Basic there literally is a single canonical string, and it's not uncommon to see people send you links like https://user:somepasswordhere@example.com.

I think the arguments other commenters have made about logging, browser history storage, etc are more convincing

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

#123

Post by erikerikson »

andix wrote: post #104
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…

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

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

#124

Post by godelski »

heipei wrote: post #106
godelski wrote: post #103

Earlier quoted context omitted.

I understand, but that is not clear enough. "Public scan" can easily be misinterpreted. Honestly, when I looked at it, I didn't know what it meant. Just looked like idk maybe a mistranslation or something? Is it a scan for the public? Is the scanning done in public? Are the results public? Who knows. Remember that I'm not tech literate and didn't make the project. I'd suggest having two buttons, "public scan" "privat…

Thanks, that is great feedback and we'll try to improve how the scan visibility is shown and what it actually means. The suggestion of adding a text to the loading page is a great idea, and the feedback about the colors on the result page is totally valid. I'm the last person who wants to see private data accidentally leak into the public domain. However experience has shown that combating the massive amounts of frau…

And thank you for being receptive and listening! I hope my thoughts and others can help make your tools better.

I really appreciate that people like you are out there trying to defend our data and privacy. I know it is such a difficult problem to solve and you got a lot of work ahead of you. But appreciation is often not said enough and left implied. So I want to make it explicit: Thank you.

(and I'll say this interaction is the best advertisement you could make, at least to me haha)

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

#125

Post by r2b2 »

andix wrote: post #104
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…

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

Correct, DNS only queries the hostname portion of the URL.

Maybe my attempt to be thorough – by making note of DNS along side HTTP since it's part of the browser ↔ network ↔ server request diagram – was too thorough.

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

#126

Post by phyzome »

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…

Huge qualifier: Even otherwise benign Javascript running on that page can pass the fragment anywhere on the internet. Putting stuff in the fragment helps, but it's not perfect. And I don't just mean this in an ideal sense -- I've actually seen private tokens leak from the fragment this way multiple times.

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

#128

Post by tobyjsullivan »

internetter wrote: post #29
tobyjsullivan wrote: post #23

Earlier quoted context omitted.

The suggestion (in both the article and the parent) is that the platforms themselves are submitting URLs. For example, if I send a link in Discord[0] DM, it might show the recipient a message like “warning: this link is malicious”. How does it know that? It submitted the url to one of these services without your explicit consent. [0] Discord is a hypothetical example. I don’t know if they have this feature. But an in…

Where in the article does it suggest this? The two bullet points at the very top of TFA is what I cited to discredit this notion, I read it again and still haven't found anything suggesting the communication platforms are submitting this themselves.

I thought I read it in the article but I may have unconsciously extrapolated from and/or misread this part:

“I came across this wonderful analysis by Positive Security[0] who focused on urlscan.io and used canary tokens to detect potential automated sources (security tools scanning emails for potentially malicious [links])”

I don’t see any mention of messaging platforms generally. It only mentions email and does not suggest who might be operating the tooling (vendor or end users). So I seem to have miscredited that idea.

[0] https://positive.security/blog/urlscan-data-leaks

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

#129

Post by FrustratedMonky »

internetter wrote: post #5
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^…

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.

"public search engine indexes"

Then it should be the search engine at fault.

If you leave your house unlocked is one thing.

If there is a company trying everyone's doors, then posting a sign in the yard "this house is unlocked", has to account for something.

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

#130

Post by [deleted] »

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

[deleted]
Post reply on HN