Breaking news: Security by obscurity isn't actually security
Well, I like my password/ssh private key to be kept in obscurity.
If you use an HSM you wouldn’t have to worry about that either
You cannot simply publicly access private secure links, can you?
131–140 of 226 posts
Re: You cannot simply publicly access private secure links, can you?
#132Earlier quoted context omitted.
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…
Do you know if safe links is guilty of the issue in the OP?
I suspect not because Microsoft is using their own internal system.
However, it likely exposes the content internally to Microsoft.
They do 100% break Salesforce password reset links, which is a major PITA.
Re: You cannot simply publicly access private secure links, can you?
#133Earlier 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
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).
Re: You cannot simply publicly access private secure links, can you?
#134Earlier 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…
> how different is it really to have the "secret" be in the URL vs in a token you submit as part of the request for the URL? 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 visibl…
In this case it's package archives, so they're never accessed from a browser, only from the Nix daemon for binary substitution [1]: https://nixos.wiki/wiki/Binary_Cache
Re: You cannot simply publicly access private secure links, can you?
#135To 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…
> Ex. When links.com?token= is visited, that link will be transmitted and potentially saved (search parameters included) by intermediaries like Cloud Flare. 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.
Cloudflare, Akamai, AWS Cloudfront are all legitimate intermediaries.
Re: You cannot simply publicly access private secure links, can you?
#136Earlier quoted context omitted.
>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.
"presigned" URLs[1] are a pretty standard and recommended way of providing users access to upload/download content to Amazon S3 buckets without needing other forms of authentication like IAM credential pair, or STS token, etc 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 li…
Interesting. I haven't built on s3, and if I did my first instinct would probably have been to gate things through a website.
Thanks for sharing your knowledge in that area.
Re: You cannot simply publicly access private secure links, can you?
#137Reminds me how some would search for bitcoin wallets via google and kazaa.
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
Re: You cannot simply publicly access private secure links, can you?
#138"private secure links" are indistinguishable from any other link.
With HTTP auth links you know the password is a password, so these tools would know which part to hide from public display:
Re: You cannot simply publicly access private secure links, can you?
#139Earlier 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.
"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.
Re: You cannot simply publicly access private secure links, can you?
#140The 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,…
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 can easily rate-limit an authentication attempt, to make brute-forcing account access practically impossible, even for a relatively insecure passwords.
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.