3 ms·

Offtopic question. All Instagram images and videos appear to be hosted a publicly accessible storage even those of private profiles. You just need to know the

Offtopic question. All Instagram images and videos appear to be hosted a publicly accessible storage even those of private profiles. You just need to know the URL. Is this security by obscurity really enough?

filleokus 7y ago
I would say so, the URLs are pretty darn long: https://scontent-arn2-2.cdninstagram.com/vp/5932ec6f480e416adb482afdbfebe189/5E47AF82/t51.2885-15/e35/74665255_2283263248631663_6646495081169154079_n.jpg?_nc_ht=scontent-arn2-2.cdninstagram.com&_nc_cat=111 https://scontent-arn2-2.cdninstagram.com/vp/5932ec6f480e416a... It's not obvious how likely it is to guess a valid URL, but even if it's just the first path, its still 128 bits (assuming a hexadecimal alphabet). According to [0] there are 50+ billion photos uploaded to Instagram. Even if we assume 10 000 billion posts (200x margin), 10^13 is a very small number in comparison to 2^128≈3.4*10^38, [0]: https://www.omnicoreagency.com/instagram-statistics/ https://www.omnicoreagency.com/instagram-statistics/ (In the the URL above I've changed one character, yielding it invalid, leaving it as an exercise for the reader to figure the missing one out.)
- deleted 7y ago
  [deleted]
hombre_fatal 7y ago
Well, you can log into any website by just guessing an unguessable token and setting a cookie. That's not what people refer to as obscurity, else all cryptography is just security through obscurity which makes it a useless distinction. You can make off with millions of dollars in bitcoin by guessing numbers correctly. It's public and yours for the taking.
gt2 7y ago
I've wondered about that on several sites. So it's true that it still requires: a) a user who should have the URL give it to them or b) person 1 guessed the URL, like a password since it's usually a long url with a GUID of some type. But is that acceptable for some reason? Easier development? Because otherwise you need to: a) issue one time/short lived token for accessing an image on S3 for instance, for all the images that will be shown on a page when a page loads for an authenticated user. or b) proxy the image requests by making an api endpoint for image names, authenticate those requests, fetch the image from a place only the server has access to and stream the image data back.
SamBam 7y ago
That's not what "security by obscurity" means. (I had the same question a while ago about something similar, so I learned the distinction.) If my secret is kept at "example.com/sadf23s[...long uuid...]" then that is not an example of security by obscurity, any more than a username/password combination is. Indeed, my long url is almost certainly much longer than the majority of user's username/password combinations. It is potentially sharable, if that's something I'm concerned about, but that can be managed via cookies, timeouts, single-use urls, etc. And I also might be ok with it being sharable, just not discoverable. (e.g. Google Sheet's distinction between "anyone with a link can access" sharing and "anyone on the internet can find and access.") "Security by obscurity" refers to relying on some part of your architecture or code being obscure. E.g. hoping that no one knows what static salt you use in your simplistic hashing function, or hoping that no one learns that there is a page called "s3cr3t-admin-access.html" that lets you get into your site without a password. The usual test is: if an attacker had access to all my source code, could they get in? In the case of randomly-generated uuids as urls, the answer is "no." "System security should not depend on the secrecy of the implementation or its components."

filleokus 7y ago

I would say so, the URLs are pretty darn long: https://scontent-arn2-2.cdninstagram.com/vp/5932ec6f480e416adb482afdbfebe189/5E47AF82/t51.2885-15/e35/74665255_2283263248631663_6646495081169154079_n.jpg?_nc_ht=scontent-arn2-2.cdninstagram.com&_nc_cat=111 https://scontent-arn2-2.cdninstagram.com/vp/5932ec6f480e416a... It's not obvious how likely it is to guess a valid URL, but even if it's just the first path, its still 128 bits (assuming a hexadecimal alphabet). According to [0] there are 50+ billion photos uploaded to Instagram. Even if we assume 10 000 billion posts (200x margin), 10^13 is a very small number in comparison to 2^128≈3.4*10^38, [0]: https://www.omnicoreagency.com/instagram-statistics/ https://www.omnicoreagency.com/instagram-statistics/ (In the the URL above I've changed one character, yielding it invalid, leaving it as an exercise for the reader to figure the missing one out.)

deleted 7y ago
[deleted]

hombre_fatal 7y ago

Well, you can log into any website by just guessing an unguessable token and setting a cookie. That's not what people refer to as obscurity, else all cryptography is just security through obscurity which makes it a useless distinction. You can make off with millions of dollars in bitcoin by guessing numbers correctly. It's public and yours for the taking.

gt2 7y ago

I've wondered about that on several sites. So it's true that it still requires: a) a user who should have the URL give it to them or b) person 1 guessed the URL, like a password since it's usually a long url with a GUID of some type. But is that acceptable for some reason? Easier development? Because otherwise you need to: a) issue one time/short lived token for accessing an image on S3 for instance, for all the images that will be shown on a page when a page loads for an authenticated user. or b) proxy the image requests by making an api endpoint for image names, authenticate those requests, fetch the image from a place only the server has access to and stream the image data back.

SamBam 7y ago

That's not what "security by obscurity" means. (I had the same question a while ago about something similar, so I learned the distinction.) If my secret is kept at "example.com/sadf23s[...long uuid...]" then that is not an example of security by obscurity, any more than a username/password combination is. Indeed, my long url is almost certainly much longer than the majority of user's username/password combinations. It is potentially sharable, if that's something I'm concerned about, but that can be managed via cookies, timeouts, single-use urls, etc. And I also might be ok with it being sharable, just not discoverable. (e.g. Google Sheet's distinction between "anyone with a link can access" sharing and "anyone on the internet can find and access.") "Security by obscurity" refers to relying on some part of your architecture or code being obscure. E.g. hoping that no one knows what static salt you use in your simplistic hashing function, or hoping that no one learns that there is a page called "s3cr3t-admin-access.html" that lets you get into your site without a password. The usual test is: if an attacker had access to all my source code, could they get in? In the case of randomly-generated uuids as urls, the answer is "no." "System security should not depend on the secrecy of the implementation or its components."