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

101–110 of 226 posts

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

#101

Post by Terr_ »

A workaround for this "email-based authentication" problem (without going to a full "make an account with a password" step) is to use temporary one-time codes, so that it doesn't matter if the URL gets accidentally shared.

1. User visits "private" link (Or even a public link where they re-enter their e-mail.)

2. Site e-mails user again with time-limited single-use code.

3. User enters temporary code to confirm ownership of e-mail.

4. Flow proceeds (e.g. with HTTP cookies/session data) with reasonable certainty that the e-mail account owner is involved.

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

#102

Post by andix »

A while ago I started to only send password protected links via email. Just with the plaintext password inside the email. This might seem absurd and unsafe on the first glance, but those kind of attacks it can safely prevent. Adding an expiration time is also a good idea, even if it is as long as a few months.

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

#103

Post by godelski »

heipei wrote: post #93
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 experie…

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" "private scan". That would contextualize the public scan to clarify and when you are scanning is publicly __listed__. And different colors. I think red for "public" would actually be the better choice.

Some information could be displayed while scanning. Idk put something like "did you know, using the public scan makes the link visible to others? This helps security researchers. You can delist it by clicking ____" or something like that and do the inverse. It should stand out. There's plenty of time while the scan happens.

> On each scan result page there is a "Report" button which will immediately de-list the scan result without any interaction from our side.

"Report" is not clear. That makes me think I want to report a problem. Also I think there is a problem with the color scheme. The pallet is nice but at least for myself, it all kinda blends in. Nothing pops. Which can be nice at times, but we want to draw the user to certain things, right? I actually didn't see the report button at first. I actually looked around, scrolled, and then even felt embarrassed when I did find it because it is in an "obvious" spot. One that I even looked at! (so extra embarrassing lol)

I think this is exactly one of those problems where when you build a tool everything seems obvious and taken care of. You clearly thought about these issues (far better than most!) but when we put things out into public, we need to see how they get used and where our assumptions miss the mark.

I do want to say thank you for making this. I am criticizing not to put you down or dismiss any of the work you've done. You've made a great tool that helps a lot of people. You should feel proud for that! I am criticizing because I want to help make the tool the best tool it can be. Of course these are my opinions. My suggestion would be to look at other opinions as well and see if there are common themes. Godelski isn't right, they're just one of many voices that you have to parse. Keep up the good work :)

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

#104

Post by andix »

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

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

#105

Post by 369548684892826 »

klabb3 wrote: post #89
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…

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?

Yes, I've seen this bot JS problem, it does happen.

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

#106

Post by heipei »

godelski wrote: post #103
heipei wrote: post #93

Earlier quoted context omitted.

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

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 fraud and malicious activity on the web nowadays requires many eyes that are able to access that data and actually do something about it. That is the reason we have these public scans in the first place.

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

#107

Post by vin10 »

godelski wrote: post #103
heipei wrote: post #93

Earlier quoted context omitted.

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

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…

This is a very well formulated suggestion. Nicely written!

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

#108

Post by r2b2 »

klabb3 wrote: post #89
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…

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 access to the same session storage.

An alternative to the in-browser-secret, is doing a browser fingerprint match. If the browser that opens the link doesn't match the fingerprint of the browser that requested the link, then fail authentication. This also has pitfalls.

Unfortunately, if your threat model requires blocking bots that click too, your likely stuck adding some semblance of a second factor (pin/password, bio metric, hardware key, etc.).

In any case, when using link-only authentication, best to at least put sensitive user operations (payments, PII, etc.) behind a second factor at the time of operation.

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

#109

Post by pests »

deathanatos wrote: post #70
nkrisc wrote: post #42

Earlier quoted context omitted.

There’s a big difference. The latter requires information not contained in the URL to access the information.

> Here's the URL to the thing: https://example.com/a/url?secret=hunter2 This is indexable by search engines. > Here's the URL to the thing: https://example.com/a/url and the password is "hunter2". This is indexable by search engines. Yes, the latter is marginally harder, but you're still leaning on security through obscurity, here. The number of times I have had "we need to securely transmit this data!" end with exac…

Right, but you settled on the answer as well. You must communicate the password via a different medium, which is impossible with links.

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

#110

Post by dmurray »

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

Also, it would allow bad actors to just opt out of malware scans - the main vector whereby these insecure URLs were leaked.
Post reply on HN