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

111–120 of 226 posts

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

#111

Post by jmholla »

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…

> Ex. When links.com?token= is visited, that link will be transmitted and potentially saved (search parameters included) by intermediaries like Cloud Flare.

Note: When over HTTPS, the parameter string (and path) is encrypted so the intermediaries in question need to be able to decrypt your traffic to read that secret.

Everything else is right. Just wanted to provide some nuance.

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

#112

Post by panic »

overstay8930 wrote: post #18

Breaking news: Security by obscurity isn't actually security

“Security by obscurity” means using custom, unvetted cryptographic algorithms that you believe others won’t be able to attack because they’re custom (and therefore obscure). Having a key you are supposed to keep hidden isn’t security by obscurity.

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

#113

Post by nightpool »

internetter wrote: post #7
bo1024 wrote: post #6

Earlier quoted context omitted.

There's probably details I'm missing, but I think the fundamental issue is that "private" messages between people are presumed private, but actually the platforms we use to send messages do read those messages and access links in them. (I mean messages in a very broad sense, including emails, DMs, pasted links in docs, etc.)

URL scanners are not scanning links contained within platforms that require access control. They haven't guessed your password, and to my knowledge no communications platform is feeding all links behind authentication into one of these public URL scanning databases. As the article acknowledged in the beginning, these links are either exposed as the result of deliberate user action, or misconfigured extensions (that,…

The article says "Misconfigured scanners". Many, many enterprise communication tools have such a scanner, and if your IT team is using the free plan of whatever url scan tool they signed up for, it's a good bet that these links may end up being public.

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

#114

Post by loginatnine »

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…

It's called a fragment FYI!

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

#115

Post by nightpool »

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

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

#117

Post by anonymousDan »

bombcar wrote: post #57
internetter wrote: post #29

Earlier quoted context omitted.

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.

Falcon Sandbox is explicitly mentioned - which is a middleware that can be installed on various communication platforms (usually enterprise): https://www.crowdstrike.com/products/threat-intelligence/fal... Microsoft has "safe links": https://learn.microsoft.com/en-us/microsoft-365/security/off... - Chrome has its own thing, but there are also tons of additional hand-rolled similar features. My main annoyance is when…

Do you know if safe links is guilty of the issue in the OP?

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

#118

Post by ApolloFortyNine »

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?

I researched this a while ago when I was curious if you could put auth tokens as query params.

One of the major issues is that many logging applications will log the full url somewhere, so now your logging 'passwords'.

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

#119

Post by r2b2 »

jmholla wrote: post #111
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…

> Ex. When links.com?token= is visited, that link will be transmitted and potentially saved (search parameters included) by intermediaries like Cloud Flare. Note: When over HTTPS, the parameter string (and path) is encrypted so the intermediaries in question need to be able to decrypt your traffic to read that secret. Everything else is right. Just wanted to provide some nuance.

Good to point out. This distinction is especially important to keep in mind when thinking about when and/or who terminates TLS/SSL for your service, and any relevant threat models the service might have for the portion of the HTTP request after terminattion.

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

#120

Post by anonymousDan »

jddj wrote: post #73
ses1984 wrote: post #36

Earlier quoted context omitted.

True but if you’re generating one link per user, at what point do you lift up your head and wonder if it wouldn’t be easier to just use authentication?

The friction that semi-private links remove is that the recipient doesn't need an account for your service. Any tradeoffs should be viewed in that context.

I like how google docs does it. You can specify the email of a user allowed to access the link (doesn't need to be gmail). When they click it they will be told to check for a validation email containing a link to the actual document.
Post reply on HN