Breaking news: Security by obscurity isn't actually security
Well, I like my password/ssh private key to be kept in obscurity.
You cannot simply publicly access private secure links, can you?
51–60 of 226 posts
Re: You cannot simply publicly access private secure links, can you?
#52Earlier 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^…
You won't find a specific link, but at some point if you generate millions of urls the 1024 bits will start to return values pretty quick through bruteforce. 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.
1024 bits seems a bit too much for the birthday problem to be a thing.
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...
Re: You cannot simply publicly access private secure links, can you?
#53Earlier quoted context omitted.
Dorking is the technique of using public search engine indexes to uncover information that is presumed to be private. It has been used to uncover webcams, credit card numbers, confidential documents, and even spies. The problem is the website administers who are encoding authentication tokens into URL state, not the naive crawlers that find them.
It can be OK to put authentication tokens in urls, but those tokens need to (at a bare minimum) have short expirations.
>It can be OK to put authentication tokens in urls
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.
Re: You cannot simply publicly access private secure links, can you?
#54When it comes to the internet if something like this is not protected by anything more than a random string in a URL then they aren't really private. Same story with all the internet connected web cams you can find if you go looking. I thought we knew this already. Why doesn't the "Who is responsible" section even mention this?
Such links are very useful in an 'it's OK to have security match the use case' type of way. You don't need maximum security for everything. You just want a barrier to widespread sharing in some cases. 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 d…
> Such links are very useful in an 'it's OK to have security match the
use case'
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.
Re: You cannot simply publicly access private secure links, can you?
#55Earlier 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^…
You won't find a specific link, but at some point if you generate millions of urls the 1024 bits will start to return values pretty quick through bruteforce. 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.
> You won't find a specific link, but at some point if you generate millions of urls the 1024 bits will start to return values pretty quick through bruteforce.
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).
Re: You cannot simply publicly access private secure links, can you?
#56To 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 the hash portion by encoding it as a URL Safe Base64 string. (aka. JS Object ↔ JSON String ↔ URL Safe Base 64 String).
Re: You cannot simply publicly access private secure links, can you?
#57Earlier quoted context omitted.
The suggestion (in both the article and the parent) is that the platforms themselves are submitting URLs. For example, if I send a link in Discord[0] DM, it might show the recipient a message like “warning: this link is malicious”. How does it know that? It submitted the url to one of these services without your explicit consent. [0] Discord is a hypothetical example. I don’t know if they have this feature. But an in…
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 they kill a one-time use URL.
Re: You cannot simply publicly access private secure links, can you?
#58Zoom meeting links often have the password appended as a query parameter. Is this link a "private secure" link? Is the link without the password "private secure"?
If the password is randomized for each meeting, the URL link is not so bad, as the meeting will be dead and gone by the time the URL appears elsewhere.
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.
Re: You cannot simply publicly access private secure links, can you?
#59Earlier 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^…
You won't find a specific link, but at some point if you generate millions of urls the 1024 bits will start to return values pretty quick through bruteforce. 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.
I'm not sure your math checks out. With 1024 bits of entropy and, say, 1 trillion valid links, your chances of any one link being valid are 1/2^984
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.
Re: You cannot simply publicly access private secure links, can you?
#60Can 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?
As well as what the others have said, various bits of software make the assumption that 1) may be private and to be careful with it and 2) isn't.
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).