How secure are URLs with random strings appended to a stem (generated as hashes of content?) and kept secret, but otherwise not secured? Is it like low probability hash collisions? Could a crawler brute-force sensitive content at a useful rate to be worth it to an attacker?
Conversation
Replying to
Thinking of the security-through-obscurity model like what uses for images, where uploads are stored at URLs with stems at firebasestorage.googleapis.com
I’ve seen it elsewhere too, so seems to be a common strategy
2
1
6
To be clear I don’t know how firebase storage works. I’m guessing.
3
2
Hmm. You actually wouldn’t need to brute force if you had local access. Packet-sniffing at a router close to a target should just give you the urls right?
5
4
I’ve instinctively avoided putting anything sensitive on services that use this mechanism, which is why I’ve primarily used Roam for text, which is encrypted, and for images only when I don’t care if it goes public
4
4
Replying to
If the hash is long enough, very secure. Think Bitcoin wallet addresses...you'd have to generate an absurd number of addresses before any reasonable chance of a collision.
Replying to
What’s your sensitivity to the probability of the contents being completely exposed/available? I’d say probability is very very very low, but time compounds, and unsure of state of the art in algo crawling. Always require auth to remove this risk imo.
1
Replying to
The Web assumes that URLs don't contain secrets. So the concern would be that some tool leaks the URLs:
1. people bookmark/share URLs,
2. URLs end up in referer metadata,
3. URLs are logged, stored in analytics,
4. Webserver/cashing layer might leak URLs accessed recently
3
5
FWIW: The fragment (after # sign) is a slightly safer place for sensitive data because it is only used locally by client eg not sent to servers at HTTP layer
That avoids referer leaks but does not solve for book-marking or exposure to script
1
Replying to
My first question would be why you wouldn’t want to use a more standardized approach?
URLs alone are not great for security as they get logged in a lot of places and the tools to brute force them are getting very fast (ffuf can do thousands of requests/second)
2
Replying to
1) Not a good defense
2) The industry has invested enough in building turn-key authentication/authorization that there is not much point not building it in at this point






