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

201–210 of 226 posts

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

#201

Post by eadmund »

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…

> Another way to mitigate this issue is to store a secret in the browser that initiated the link-request (Ex. local storage).

Or just a cookie …

But this approach breaks anyway in cases such as a user on a desktop who checks his email on his phone for the confirmation.

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

#202

Post by 1231232131231 »

ablob wrote: post #151
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^…

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

Binary?

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

#203

Post by 1231232131231 »

ummonk wrote: post #154
mbrumlow wrote: post #84

Earlier quoted context omitted.

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.

Passwords usually don't show up in server logs if submitted correctly.

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

#204

Post by rapind »

conductr wrote: post #187
rapind wrote: post #184

Earlier quoted context omitted.

It certainly does. Security usually comes at the cost of convenience and can incur confusion. In this example, where best practice may be to use one time tokens, you will end up with users who click on the secure link again (from their email) in the future to access the secure site and they’ll be frustrated when they have to go through the secure link generation dance again. Of course you can mitigate this with sessi…

Some people will always find something to complain about. I feel like it’s completely reasonable to give a “sorry this link was only valid for 5 minutes and is now expired, request a new code here” message. State it in the email that originally contained the link and state it again on the page when they click it afterwards. This is incredibly common practice and very unlikely to be the first time someone has seen thi…

> State it in the email that originally contained the link and state it again on the page when they click it afterwards.

No one reads this stuff. I’m not saying this to be argumentative. I have a large user base and I know from experience.

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

#206

Post by ses1984 »

anonymousDan wrote: post #120
jddj wrote: post #73

Earlier quoted context omitted.

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.

Isn’t that basically a form of authentication?

I’m not sure if short lived temporary private links fit the model of private links as described above.

If that counts as a private link, what if I’m using a conventional session based app, I go into dev tools and “copy as curl”, does that qualify as a private link?

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

#207

Post by FrustratedMonky »

pixl97 wrote: post #198
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.

You've been appropriately downvoted for a terrible take. Imagine if you left your house unlocked it would be broken into seconds later. Even worse, the people that broke into it live in a different country with no extradition law and you'd never figure out who they are anyway. In this case your insurance company would tell you lock your damned doors and the police may even charge you under public nuisance laws.

Yeah, it is a terrible take. It's a bad situation.

Just like charging people for a crime for accessing private material, simply by browsing a public URL.

Maybe Better take:

It is like someone being charged for breaking and entering, simply by looking at a house from the street, when the door was left open. Your guilty by simply looking, and seeing inside. But you were just walking by, you saw inside before realizing it was a crime, now your guilty.

If you are going to charge people for accessing private sites, potentially by accident, by simply being provided a public URL from a search engine. Then shouldn't the search engine have some culpability?

Or. Better. Change the law so the onus is on the site to protect itself.

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

#208

Post by egberts1 »

Sure, you can!

This is the part where IP filtering by country and subnet can keep your ports hidden.

Also stateful firewall can be crafted to only let certain IP thru after sending a specially-crafted TOTP into a ICMP packet just to get into opening the firewall for your IP.

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

#209

Post by anonymousDan »

ses1984 wrote: post #206
anonymousDan wrote: post #120

Earlier quoted context omitted.

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.

Isn’t that basically a form of authentication? I’m not sure if short lived temporary private links fit the model of private links as described above. If that counts as a private link, what if I’m using a conventional session based app, I go into dev tools and “copy as curl”, does that qualify as a private link?

Yes it is. My point was more that it's a relatively lightweight way to create a shareable link that does not require the consumers to create a new account on the service hosting the linked resource in order to access it. At the same time, merely having access to the link doesn't really gain you anything, and so it is immune to the kind of issues discussed in the article

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

#210

Post by thayne »

paulgb wrote: post #192
ta1243 wrote: post #189

Earlier quoted context omitted.

> That isn't an inherent problem with having a secret in the url. The problem is the url was leaked somewhere where it could get indexed. Technically you're right -- after all sending an authentication as a separate header doesn't make any difference. GET /endpoint/?Auth=token or GET /endpoint Auth: token Sends the same data over the wire. However software treats URLs differently to headers. They sit in browser histo…

For better or worse, basic auth in the URL isn't really an option any more, (e.g. see https://stackoverflow.com/a/57193064 ). I think the issue was that it reveals the secret to anyone who can see the URL bar, but the alternative we got still has that problem and also has the problem that the secret is no longer separable from the resource identifier.

The browser could hide the secret after it is entered.
Post reply on HN