You cannot simply publicly access private secure links, can you?(vin01.github.io) |
You cannot simply publicly access private secure links, can you?(vin01.github.io) |
A GET isn’t supposed to modify server state. That is reserved for POST, PUT, PATCH…
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, you are doing it wrong. The same concept applies here. This isn’t a novel security issue, this is just another method of dorking.
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
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^1024 combinations.
Imagine it's
https://site,com/[32chars][32chars] instead.
But while guessing the former is harder than the latter, URLs leak a lot, far more than passwords.
The problem is the website administers who are encoding authentication tokens into URL state, not the naive crawlers that find them.
How would you do that for the URLs? 5 requests to site.com/[256chars] which all 404 block your IP because you don't have a real link? I guess the security is relying on the fact that only a very a small percentage of the total possible links would be used? Though the likelihood of randomly guessing a link is the same as the % of addressable links used.
Did you do that just to upset me?
The one link won't be found quickly, but a bunch of links will. You just need to fetch all possibilities and you'll get data.
If the actual websites are configured to not use the URL as the authentication state, all this would be avoided
And I think for me it comes down to the fact that the tokens can be issued on a per-customer basis, and access logs can be monitored to watch for suspicious behaviour and revoke accordingly.
Also, as others have mentioned, there's just a different mindset around how much it matters that the list of names of files be kept a secret. On the scale of things Amazon might randomly screw up, accidentally listing the filenames sitting in your public bucket sounds pretty low on the priority list since 99% of their users wouldn't care.
I'm not sure I grok this. Do you mean, for example, sending a token in the POST body, or as a cookie / other header?
One disadvantage to having a secret in the URL, versus in a header or body, is that it can appear in web service logs, unless you use a URI fragment. Even then, the URL is visible to the user, and will live in their history and URL bar - from which they may copy and paste it elsewhere.
Extremely different. The former depends on the existence of a contract about URL privacy (not to mention third parties actually adhering to it) when no such contract exists. Any design for an auth/auth mechanism that depends on private links is inherently broken. The very phrase "private link" is an oxymoron.
> I am not sure why you think that having an obscure URI format will somehow give you a secure call (whatever that means). Identifiers are public information.
<https://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypert...>
One of those little informative pieces where everytime I do AWS now all the bucket names are usually named <project>-<deterministic hash from a seed value>.
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).
Is there a difference between a private link containing a password and a link taking you to a site where you input the password? Bitwarden Send gives a link that you can hand out to others. It has # followed by a long random string. I'd like to know if there are security issues, because I use it regularly. At least with the link, I can kill it, and I can automatically have it die after a few days. Passwords generally don't work that way.
Sending a GET request to a site for the password-input screen and POST'ing the password will get very different treatement than sending the same amount of "authorization bits" in the URL; in the first case, your browser won't store the secret in the history, the webserver and reverse proxy won't include it in their logs, various tools won't consider it appropriate to cache, etc, etc.
Our software infrastructure is built on an assumption that URLs aren't really sensitive, not like form content, and so they get far more sloppy treatment in many places.
If the secret URL is short-lived or preferably single-use-only (as e.g. many password reset links) then that's not an issue, but if you want to keep something secret long-term, then using it in an URL means it's very likely to get placed in various places which don't really try to keep things secret.
Ex. When links.com?token=<secret> is visited, that link will be transmitted and potentially saved (search parameters included) by intermediaries like Cloud Flare.
Ex. When links.com#<secret> is visited, the hash portion will not leave the browser.
Note: It's often nice to work with data in the hash portion by encoding it as a URL Safe Base64 string. (aka. JS Object ↔ JSON String ↔ URL Safe Base 64 String).
Access control on anything that is not short-lived must be done outside of the url.
When you share links on any channel that is not e2ee, the first agent to access that url is not the person you're sending it to, it is the channel's service, it can be legitimate like Bitwarden looking for favicons to enhance UX, or malicious like FB Messenger crawler that wants to know more about what you are sharing in private messages.
Tools like these scanners won't get better UX, because if you explicitly tell users that the scans are public, some of them will think twice about using the service, and this is bad for business, wether they're using it for free or paying a pro license.
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 directly shown to the user (although they can probably see them in the browser debug view).
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.
Any source for this? Do you work there? I checked their docs and they say they don't "mine user data", so I wouldn't trust anything they say, at least outside legal documents.
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?
Cookie auth only works if the CDN is on the same domain, even a subdomain can be problematic in many cases.
But in reality, nobody actually cares and just wants a "click to join" that doesn't require fumbling around - but the previous "just use the meeting ID" was too easily guessed.
With HTTP auth links you know the password is a password, so these tools would know which part to hide from public display:
I know there are valid reasons (the "are you sure you want to log in as usernam on example.com?" prompt for example) but this is just one of the many ways web dev has built hacks upon hacks where implementing standards would've sufficed. See also: S3 vs WebDAV.
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 delist.
urlscan.io does a bit better but the language is not quite clear that it means the scan is visible to the public. And the colors just blend in. If something isn't catching to your eye, it might as well be treated as invisible. If there is a way to easily misinterpret language, it will always be misinterpreted. if you have to scroll to find something, it'll never be found.
For example, either a special HTTP header returned when making a HEAD request for the URL, or downloading a file similar to robots.txt that defines globs which are public/private.
At least this would (mostly) avoid these links becoming publicly available on the internetz.
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.
We are just getting started but so far we are loving the ergonomics.
* this obviously assumes the objects have a 1-1 mapping with users
On a side note, can someome remind me what was the name of the file, I think I have some tiny fraction of a bicoin on an old computer
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.
I am not completely opposed to scripting web pages (it’s a useful capability), but the vast majority of web pages are just styled text and images: Javascript adds nothing but vulnerability.
It would be awesome if something like HTMX were baked into browsers, and if enabling Javascript were something a user would have to do manually when visiting a page — just like Flash and Java applets back in the day.
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.
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?
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.
Meanwhile our HTTP servers happily log every URI it received in access logs. Oh, and if you ever send a link in non E2EE messenger it's likely their server generated the link preview for you.
Example 1:
Alice wants Bob to see CoolDocument. Alice generates a URL that has the snowflake in the URL and gives it to Bob. Eve manages to see the chat, and can now access the document.
Example 2:
Alice wants Bob to see CoolDocument. Alice clicks "Share with Bob" in the app, grabs the URL to the document with no authentication encoded within and sends it to Bob. Bob clicks the link, is prompted to login, Bob sees the document. Eve manages to see the chat, follows the link, but is unable to login and thus cannot see the document.
Later, Alice wants to revoke Bob's access to the document. Lots of platforms don't offer great tools to revoke individual generated share URLs, so it can be challenging to revoke Bob's access without potentially cutting off other people's access in Example 1, as that link might have been shared with multiple people. In example 2, Alice just removes Bob's access to the doucment and now his login doesn't have permissions to see it. Granted, better link management tools could sovle this, but it often seems like these snowflake systems don't really expose a lot of control over multiple share links.
You mean mathematically there is no difference. Functionally there is a very, very big difference.
Unfortunately, it's based on the document ID, so you can't re-enable access with a new URL.
As an example i hit 'create link share' on a photo in my photo gallery and send someone the link to that photo. I don't want them to have to enter a password. I want the link to show the photo. It's ok for the link to do this. One of the examples they have here is exactly that and it's fine for that use case. In terms of privacy fears the end user could re-share a screenshot at that point anyway even if there was a login. The security matches the use case. The user now has a link to a photo, they could reshare but i trust they won't intentionally do this.
The big issue here isn't the links imho. It's the security analysis tools scanning all links a user received via email and making them available to other users in that community. That's more re-sharing than i intended when i sent someone a photo.
I think you give the most sensible summary. It's about "appropriate and proportional" security for the ease of use trade-off.
> the user now has a link to a photo, they could reshare but i trust they won't intentionally do this.
Time limits are something missing from most applications to create ephemeral links. Ideally you'd want to choose from something like 1 hour, 12 hours, 24 hours, 72 hours... Just resend if they miss the message and it expires.
A good trick is to set a cron job on your VPS to clear /www/tmp/ at midnight every other day.
> The big issue here isn't the links imho. It's the security analysis tools scanning all links a user received via email
You have to consider anything sent to a recipient of Gmail, Microsoft, Apple - any of the commercial providers - to be immediately compromised. If sending between private domains on unencrypted email then it's immediately compromised by your friendly local intelligence agency. If using PGP or am E2E chat app, assume it _will_ be compromised at the end point eventually, so use an ephemeral link.
In practice, there is.
There is a difference between something-you-have secrets and something-you-know secrets.
A UrL is something you have. It can be taken from you if you leave it somewhere accessible. Passwords are something-you-know and if managed well can not be taken (except for the lead pipe attack).
There is also something-you-are, which includes retina and fingerprint scans.
(1) Requires some out-of-band information to authenticate. Information that people are used to keeping safe.
On the other hand the URLs in (2) are handled as URLs. URLs are often logged, recorded, shared, passed around. E.g. your work firewall logging the username and password you used to log into a service would obviously be bad, but logging URLs you've accessed would probably seems fine.
[the latter case is just an example - the E2E guarantees of TLS mean that neither should be accessible]
1. "Password" is a magic word that makes people less likely to just paste it into anything.
2. Username + passwords are two separate pieces of information that are not normally copy-pasted at the same time or have a canonical way of being stored next to each other.
One of the major issues is that many logging applications will log the full url somewhere, so now your logging 'passwords'.
eg Your web browser will automatically save any URLs to it's history for any user of the computer to see but will ask first before saving passwords.
eg Any web proxies your traffic goes through or other software that's looking like virus scanners will probably log URLs but probably won't log form contents (yes HTTPS makes this one more complicated but still).
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 :)
This is a valid argument. However, I'd say that there are two standard practices with links that are a big advantage: giving them a short life, and generating extremely hard to guess URLs. I was a Lastpass customer before their security problems came out. I had many passwords that I made years ago but don't use the service any longer. I moved more into the URL camp at that time. Who knows how many passwords I made 15 or 20 years ago that today are no longer secure.
https://arstechnica.com/tech-policy/2014/02/french-journalis...
probably better to solve that problem by just giving projects easy-to-remember codenames. that's what intelligence agencies and militaries have been doing for years after all
When opening a Dropbox/GoogleDocs/OneDrive link, I expect the application not to route them through potentially unsafe CDNs.
e.g. configuring an sshd accepting password auth and unlimited retries to listen on a non-22 port is "security by obscurity". configuring an sshd to disallow root logins, disallow password authentication, only accept connections from a subset of "trustworthy" IP addresses, and listen on a non-22 port, is "security with obscurity"
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.
[0] Discord is a hypothetical example. I don’t know if they have this feature. But an increasing number of platforms do.
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 they kill a one-time use URL.
“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.
> We will never sell your data or use it to target ads.
https://developers.cloudflare.com/1.1.1.1/privacy/public-dns...
> Cloudflare will not sell or share Public Resolver users’ personal data with third parties or use personal data from the Public Resolver to target any user with advertisements.
There's a lot of transparency on that page in particular, down to the lists of the fields in the logs.
* Parties can engage in price discrimination against you. (You don't shop around? you've got some extra spending money? double prices! Looking up risky activities? high insurance rates!)
* Parties can engage in lawfare and blackmail
* Parties can influence elections (without advertising, e.g. by gerrymandering or by targeting your participation in elections just based on knowing how you'll vote)
* Parties can target people of your race or beliefs for genocide (oh, sorry, I meant to say "lawful orders of governments")
Plus the definition of advertising itself is up to interpretation: is sending someone to your door advertising?
I wouldn't trust them even if it were in legal docs. Companies have a long history of being perfectly fine with breaking the law when doing so is profitable, especially when they're likely to get little more than a slap on the wrist when caught, and the odds of being caught in the first place are slim.
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 exactly or something equivalent to emailing an encrypted ZIP with the password in the body of the email (or sometimes, some other insecure channel…) …
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..
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.
I think the arguments other commenters have made about logging, browser history storage, etc are more convincing
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.
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)
Or are you saying its a pain for you, Eve, not being able to see Bob's documents so easily?
And when I'm replying to someone on HN, I never have to worry "do they have an HN account already?".
Any tradeoffs should be viewed in that context.
However, it likely exposes the content internally to Microsoft.
They do 100% break Salesforce password reset links, which is a major PITA.
Not even close. 1024 bits is a really, really big address space.
For the sake of argument and round numbers, let's say that there are 4.2 billion (2^32) valid URLs. That means that one out of every 2^992 randomly generated URLs is valid. Even if you guessed billions of URLs every second, the expected time to come up with a valid one (~2^960 seconds) is still many orders of magnitude greater than the age of the universe (~2^59 seconds).
So test a million links - your probability of finding a real one is (1-1/2^984)^1000000. That's around 1/10^291 chance of hitting a valid URL with a million tries. Even if you avoid ever checking the same URL twice it will still take you an impractical amount of time.
I looked at [1] to do the calculation but (2^1024)! is a number too large for any of my tools. If someone has a math shortcut to test this idea properly...
[1] https://en.wikipedia.org/wiki/Birthday_problem#Calculating_t...
(Well, before you apply the logistic taper to it. So you wanted an approximation? There you go. Until you get the chance of a hit to be quite high, it's basically equal to guesses * valid links / 2^1024.)
You'd get far more return on investment breaking bitcoin wallets.
2^1024 is 10^308
Lets say there are 12 billion links per person, and 8 billion people. That's 100 billion billion, or 10^20 links.
10^20 / 10^308 is zero.
Lets say you can test 10 trillion links a second, and started when the big bang happened, you'll have tested 10^30 links so far.
The number of links you'll have found so far is zero.
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?
And sometimes it isn't practical to require a POST request or a cookie.
And the risk of a url leaking can be greatly mitigated if the url is only valid for a short period of time.
Technically you're right -- after all sending an authentication as a separate header doesn't make any difference.
GET /endpoint/?Auth=token
GET /endpoint
Auth: token
However software treats URLs differently to headers. They sit in browser histories, server logs, get parsed by MITM firewalls, mined by browser extensions, etc
using https://user:pass@site.com/endpoint or https://auth:token@site.com/endpoint
Would be better than
https://site.com/endpoint/user/pass or https://site.com/endpoint/?auth=token
As the former is less likely to be stored, either on the client or on the server. I don't do front end (or backend authentication -- I just rely on x509 client certs or oidc and the web server passes the validated username)
When would this ever be necessary? URL session tokens have been a bad idea ever since they first appeared.
The only things even near to auth tokens I can reasonably see stuffed into a URL are password reset and email confirmation tokens sent to email for one time short expiration use.
Outside of that, I don't see any reason for it.
Web Applications do utilize this pattern very frequently
But as noted i previous comment these do have short expiry times (configurable) so that there is no permanent or long-term risk on the lines of the OP article
[1]: https://docs.aws.amazon.com/AmazonS3/latest/userguide/using-...
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
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).
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.
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.
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.
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.
If that sounds ridiculous, it’s because it is. And yet, add in a computer and the Internet, and that’s basically what a newly unsealed federal indictment accuses Florida journalist Tim Burke of doing when he found and disseminated outtakes of Tucker Carlson’s Fox News interview with Ye, the artist formerly known as Kanye West, going on the first of many antisemitic diatribes.""
https://arstechnica.com/tech-policy/2024/03/charges-against-...
"According to Burke, the video of Carlson’s interview with Ye was streamed via a publicly available, unencrypted URL that anyone could access by typing the address into your browser."
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.
And that are single-use.
(Your password reset "magic link" should expire quickly, but needs a long enough window to allow for slow mail transport. But once it's used the first time, it should be revoked so it cannot be used again even inside that timeout window.)
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
Just by looking, you are guilty. That is wrong.
From https://urlscan.io/blog/2022/07/11/urlscan-pro-product-updat...
> In the process of scanning websites, urlscan.io will sometimes encounter file downloads triggered by the website. If we are able to successfully download the file, we will store it, hash it and make it available for downloading by our customers.
Thanks for sharing your knowledge in that area.
Spammers would sign up for services that required a click on a link using blabla@domainusingsuchservice
The services bots to check phishing would reliably click on the link, rendering the account creation valid.
One particularly exploitable vendor for getting such links clicked was one that shares the name with a predatory fish that also has a song about it :)
t. security auditor/researcher.
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 sessions / cookies, but that is also a security compromise and not device portable.
It’s easy to say that these are minor uxp concerns, but enforcing a high level of security may have a significant user cost depending on your demographic. I have a demographic that skews older and non technical and they are pretty loud when they complain about this stuff… meanwhile they are also more likely to reuse passwords and forward emails with secure links in them!
Or are you just saying, sometimes a user will receive their authenticated URL on the verified channel and then self-leak it on another channel? In which case, it really doesn't matter what that other channel is...
No one reads this stuff. I’m not saying this to be argumentative. I have a large user base and I know from experience.
It’s also why you say it on the site when the link is found to be expired. You basically remind them of the email even though they didn’t read it. Just consistent messaging is all. It might reduce the number of folks that decide to yell at you over it but will never fully eliminate them.
IMO the appropriate easy button is them using a password manager which is what I’d recommend. Also, just ignore these complaints if they don’t take your explanation and really push hard it’s a customer not worth pleasing at some point.