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

141–150 of 226 posts

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

#141

Post by laurels-marts »

ApolloFortyNine wrote: post #118
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'.

You can definitely pass JWT as a query param (and often are in embedded scenarios) and no its not the same as logging passwords unless you literally place the password in the payload (which would be stupid).

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

#142

Post by fddrdplktrew »

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

legend.

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

#143

Post by FrustratedMonky »

lmm wrote: post #139
FrustratedMonky wrote: post #129

Earlier quoted context omitted.

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

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.

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

#144

Post by zer00eyz »

tsimionescu wrote: post #133
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

Actually, there are cases where this is more or less unavoidable. For example, if you want a web socket server that is accessible from a browser, you need authentication, and can't rely on cookies, the only option is to encode the Auth information in the URL (since browsers don't allow custom headers in the initial HTTP request for negotiating a web socket).

Authentication: Identify yourself

Authorization: Can you use this service.

Access Control/Tokenization: How long can this service be used for.

I swipe my badge on the card reader. The lock unlocks.

Should we leave a handy door stopper or 2x4 there, so you can just leave it propped open? Or should we have tokens that expire in a reasonable time frame.. say a block of ice (in our door metaphor) so it disappears at some point in future? Nonce tokens have been a well understood pattern for a long time...

Its not that these things are unavoidable its that security isnt first principal, or easy to embed due to issues of design.

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

#145

Post by skissane »

tsimionescu wrote: post #133
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

Actually, there are cases where this is more or less unavoidable. For example, if you want a web socket server that is accessible from a browser, you need authentication, and can't rely on cookies, the only option is to encode the Auth information in the URL (since browsers don't allow custom headers in the initial HTTP request for negotiating a web socket).

> the only option is to encode the Auth information in the URL (since browsers don't allow custom headers in the initial HTTP request for negotiating a web socket).

Put a timestamp in the token and sign it with a private key, so that the token expires after a defined time period.

If the URL is only valid for the next five minutes, the odds that the URL will leak and be exploited in that five minute window is very low

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

#146

Post by shiomiru »

loginatnine wrote: post #114
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!

However, window.location calls it "hash". (Also, the query string is "search". I wonder why Netscape named them this way...)

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

#147

Post by maxcoder4 »

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

The idea behind "security thorough obscurity" is that even if the adversary knows everything about your setup *except the secret keys*, you should be secure. Security through obscurity is any method of protection other than the secret key, like for example: * serving ssh on a random high port * using a custom secret encryption algorithm * hosting an unauthenticated service on a secret subdomain in hope nobody will find out * or with a long directory name

Some security thorough obscurity is OK (for example high ports or port knocking help buy time when protecting from a zeroday on the service). It's just that relying only on the security thorough obscurity is bad.

In this case, I wouldn't call URLs with embedded key security through obscurity, just a poor key management.

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

#148

Post by klabb3 »

r2b2 wrote: post #108
klabb3 wrote: post #89

Earlier quoted context omitted.

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?

To somewhat mitigate the link-loading bot issue, the link can land on a "confirm sign in" page with a button the user must click to trigger the POST request that completes authentication. Another way to mitigate this issue is to store a secret in the browser that initiated the link-request (Ex. local storage). However, this can easily break in situations like private mode, where a new tab/window is opened without acc…

> a button the user must click

Makes sense. No action until the user clicks something on the page. One extra step but better than having “helpful bots” wreak havoc.

> to store a secret in the browser […] is doing a browser fingerprint match

I get the idea but I really dislike this. Assuming the user will use the same device or browser is an anti-pattern that causes problems with people especially while crossing the mobile-desktop boundary. Generally any web functionality shouldn’t be browser dependent. Especially hidden state like that..

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

#149

Post by XorNot »

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 script to list buckets with "friendly" names.

There's always a weird tradeoff with hosted services where technically the perfect thing (totally random identifiers) is too likely to mostly be an operational burden compared to the imperfect thing (descriptive names).

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

#150

Post by Sn0wCoder »

nmadden wrote: post #48
mikepurvis wrote: post #34

Earlier quoted context omitted.

Bit of a tangent, but I was recently advised by a consultant that pushing private Nix closures to a publicly-accessible S3 bucket was fine since each NAR file has a giant hash in the name. I didn't feel comfortable with it so we ended up going a different route, but I've continued to think about that since how different is it really to have the "secret" be in the URL vs in a token you submit as part of the request fo…

I wrote about putting secrets in URLs a few years ago: https://neilmadden.blog/2019/01/16/can-you-ever-safely-inclu...

Question in the Waterken-Key flow with token in the URL fragment the URL looks like HTTPS www.example.com/APP/#mhbqcmmva5ja3 – but in the diagram its hitting example.com/API/#mhbqcmmva5ja3 Is this a type-o OR are we mapping APP to API with the proxy so the user thinks they are going to the APP with their Key. Or does the browser do us for us automatically when it sees app in the URL and then stores the key in window.location.hash. I am confused and might just find the answer on Google but since you appear to be the author maybe you can answer the question here.
Post reply on HN