It’s not security through obscurity in this case. The filenames can’t be obtained or guessed through brute force. At least not with current technology or processing power…
Security through obscurity is when you hide implementation details.
Saying that my suggestion is security through obscurity is the same as telling that ASLR is security through obscurity…
Not really sure what you mean by reusing UUIDs but theres nothing bad about using UUIDs in URLs for content you don’t want scrapped by bots. Sites like Google Photos are already are using UUIDs in the URL for the photos, and do not require any authentication to see the image as long as you have the URL. You can try this for yourself and copy the URL of an image and open it in a Private Browsing Window. Every so often someone realizes the actual image URL is public and think they’ve found a serious issue, but the reason why it isn’t is because of the massive key space UUID provides and that it would be infeasible to check every possible URL, even if it’s publicly available.
You point out the “vulnerability” yourself, sometimes (when it’s Google) it works as designed, but a less robust site could have the full access through a UUID for example and then someone shares an image with it, bam they have access to more than they should. The history is littered with bulletproof things like this ending up being used wrongly.
Disabling index and making the names UUID would make the directory inviolable even if the address was publicly available.
Security through obscurity never works.
It’s not security through obscurity in this case. The filenames can’t be obtained or guessed through brute force. At least not with current technology or processing power…
Security through obscurity is when you hide implementation details.
Saying that my suggestion is security through obscurity is the same as telling that ASLR is security through obscurity…
Until the psuedo random UUID generator can be reverse engineered. Makes me think of this video: https://youtu.be/o5IySpAkThg
Anyway, I think we’re on the same wavelength and both agree that the implementation as is isn’t production-ready to say the least ;)
Bet you could reuse/keep UUIDs for someone/stuff that gets updated and get that new data even if you “shouldn’t”.
It could work in theory but in practice there are always a billion things that go wrong IMO.
Not really sure what you mean by reusing UUIDs but theres nothing bad about using UUIDs in URLs for content you don’t want scrapped by bots. Sites like Google Photos are already are using UUIDs in the URL for the photos, and do not require any authentication to see the image as long as you have the URL. You can try this for yourself and copy the URL of an image and open it in a Private Browsing Window. Every so often someone realizes the actual image URL is public and think they’ve found a serious issue, but the reason why it isn’t is because of the massive key space UUID provides and that it would be infeasible to check every possible URL, even if it’s publicly available.
You point out the “vulnerability” yourself, sometimes (when it’s Google) it works as designed, but a less robust site could have the full access through a UUID for example and then someone shares an image with it, bam they have access to more than they should. The history is littered with bulletproof things like this ending up being used wrongly.