4 ms·

I think it's pretty safe as long as no one without the permissions can find (or guess/extrapolate) that URL. The images are probably just hosted by a CDN and se

I think it's pretty safe as long as no one without the permissions can find (or guess/extrapolate) that URL. The images are probably just hosted by a CDN and serving up the files with authentication might slow it down or complicate the setup.

skbohra123 16y ago
So, this is the ideal way to host static files? I think this is something like a pseudo security, isn't it? What we call is 'ostrich' approach to security. There must be some better way to do this.
- tptacek 16y ago
  Requiring attackers to guess a 128 bit random number (actually, fbcdn seems to use 136 bit random numbers) isn't "psuedo" security.
  - thomas11 16y ago
    The problem is that the random number is static. As Aegan says, anyone allowed to see a photo can leak its URL. It would be better if the URL would depend on the user to whom the picture is served. But that'd be expensive.
    - tptacek 16y ago
      Anyone allowed to see a photo can leak the photo. Why waste time protecting the ID?
      - thomas11 16y ago
        Sure, in practice there's not much of a difference, I'm nitpicking, but it's not exactly the same thing. People might leak the URL unintentionally, for instance by sending the link to others, not knowing that the photo owner doesn't want them to see the photo. One can also use URLs in places where images are not allowed, for example when submitting them to community websites, without first uploading the photo somewhere and leaving a trail.
  - jcroberts 16y ago
    Thomas, I agree with you on all points you've posted _except_ the difficulty of attacking the system. It cannot be a truly random number of "X" bits because it is used as a permanent unique identifier. If it was actually a random number, then you have the potential of overwriting files and/or reusing URLs/UIDs. For every UID discovered, the entropy shrinks and the system becomes easier to attack. Of course, I'm not saying the shrinking entropy would make it feasible to attack the system, just easier. ;)
    - tptacek 16y ago
      This is a great noodley point, but note that they can just increase the width of the identifier to maintain a constant threshold level of entropy. They won't, of course. But they could.
      - jcroberts 16y ago
        We can rest assured that facebook simply doesn't care about this non-issue of image access, so increasing the bit width is not worth their time, but assuming someone actually had this need, doing it right is a lot more complicated than it seems at first glance. --Again, this is admittedly another annoying "noodley point" but it could be important for someone. ASSUMING: The systems are most likely run in virtual machines, and the UID's are most likely the keys for a key-value store. Whether or not the UID are specific to just images, or are also used for other things (wall posts or whatever) is unknown. The first question is whether or not your key-value store can handle the increase in key length (UID). Since this is fixable, the safe assumption is "yes" albeit there might be undesirable (or even unsurmountable) performance penalties. A good PRNG is fed by a system entropy pool, and the pool is populated by various system entropy sources. Some believe virtualization can make the system entropy pool more predictable, but some believe virtualization can make the system entropy pool less predictable. It doesn't really matter which is true. The important point is if you can exhaust the system entropy pool, one of two things will happen; (1) the system will get bogged down waiting on the pool, or (2) a poorly written PRNG will start giving you less random numbers. Of course, "less random" is the most accurate way to phrase it, but in some cases, the actual result is the (faulty) PRNG gives you "predicable" numbers if the system entropy pool is exhausted. To do it right, you'd have to evaluate the frequency/pressure on the system entropy pool before increasing the key/UID width or you might suffer some highly undesirable effects. There are essentially two places where you might need to add hardware; (1) performance penalties of increased key width in the key-value store, and (2) performance penalties from exhaustion of the system entropy pool (with a well written PRNG). With the former you'd be paying for more servers, and with the latter you'd be paying for more entropy sources to feed the pools. I'm not sure how one would add specialized entropy source hardware in a virtualized environment, but with enough cost and effort, it might be doable (device mapping?). Needless to say, in either case or both, the costs could be prohibitive. The admittedly "noodley" point here is correctly maintaining a constant threshold level of entropy is occasionally easier said than done. Of course, in other cases, it might be brain dead simple to maintain a constant threshold. The only way to figure it out is proper testing. The non-power-of-two 136 bit length you mentioned seems interesting. I might be (incorrectly) reading more into it that is actually there, but I believe it hints at a far more cost effective solution, namely, just add more k-v stores. For example, the key/UID could only be 128 bits wide, and the extra eight bits indicate a particular k-v store. With the k-v stores being located "close" to the user, this could also improve bandwidth costs, usability/latency, and load balancing, in addition to the benefits of the CDN. I don't have a facebook account, so I can't check, but if there's some degree of predictability in a single byte (leading, trailing, middle, ?) of the UID, it would be further support of the above theory of operation. It doesn't need to be perfectly consistent, since at each location there are probably multiple k-v stores. Even on a collision of a generated key/uid in a particular k-v store, the UID might not be thrown out unless it was already used in _all_ of the local k-v stores. This would further reduce the pressure on the system entropy pool, but due to the need for replication/redundancy/backup, I seriously doubt this is the case. Though going from 128 bit to 136 bit (or similar) _is_ an increase of the width of the identifier, it probably has nothing to do with maintaining a constant threshold of entropy. It's probably just a smart business decision to reduce hardware/bandwidth costs. PLEASE NOTE: The above is only mindless speculation about how the 136 bit UIDs/keys might work, and (hopefully) no one at facebook will confirm or deny it.
- Aegean 16y ago
  I am surprised this is standard behavior. So if I allow user X to see my photos it means that user has a right to publish all my photo urls. It doesn't look good to me.
  - skbohra123 16y ago
    Clearly this is something that that makes this issue even more dangerous.
  - DrJokepu 16y ago
    How is that any different from being able to save the photo as a file and upload it to a free image hosting site? From a security point of view? Since it can be easily circumvented anyway, disallowing sharing static photo URLs would be the real "pseudo security", in my opinion.
    - tptacek 16y ago
      It's different because in this case if someone dumps all your photo links Facebook can in theory just assign them new random secret IDs, whereas if someone uploads your photos to a hosting site there's nothing they can do about it. In other words, from a security perspective, it is in no way worse.
- jules 16y ago
  Are passwords pseudo security too? They are easier to guess than a random url. That one is entered in a form field and the other in the url bar doesn't really matter does it?
  - tptacek 16y ago
    It sort of does, since your browser knows that it needs to be carefuly with things you plug into password fields, and doesn't know that it needs to be careful with random URLs. But that's less of an issue with a hidden IMG tag.
  - arethuza 16y ago
    People are unlikely to share passwords - they are highly likely to share links via email or IM.

skbohra123 16y ago

So, this is the ideal way to host static files? I think this is something like a pseudo security, isn't it? What we call is 'ostrich' approach to security. There must be some better way to do this.

tptacek 16y ago
Requiring attackers to guess a 128 bit random number (actually, fbcdn seems to use 136 bit random numbers) isn't "psuedo" security.
- thomas11 16y ago
  The problem is that the random number is static. As Aegan says, anyone allowed to see a photo can leak its URL. It would be better if the URL would depend on the user to whom the picture is served. But that'd be expensive.
  - tptacek 16y ago
    Anyone allowed to see a photo can leak the photo. Why waste time protecting the ID?
    - thomas11 16y ago
      Sure, in practice there's not much of a difference, I'm nitpicking, but it's not exactly the same thing. People might leak the URL unintentionally, for instance by sending the link to others, not knowing that the photo owner doesn't want them to see the photo. One can also use URLs in places where images are not allowed, for example when submitting them to community websites, without first uploading the photo somewhere and leaving a trail.
- jcroberts 16y ago
  Thomas, I agree with you on all points you've posted _except_ the difficulty of attacking the system. It cannot be a truly random number of "X" bits because it is used as a permanent unique identifier. If it was actually a random number, then you have the potential of overwriting files and/or reusing URLs/UIDs. For every UID discovered, the entropy shrinks and the system becomes easier to attack. Of course, I'm not saying the shrinking entropy would make it feasible to attack the system, just easier. ;)
  - tptacek 16y ago
    This is a great noodley point, but note that they can just increase the width of the identifier to maintain a constant threshold level of entropy. They won't, of course. But they could.
    - jcroberts 16y ago
      We can rest assured that facebook simply doesn't care about this non-issue of image access, so increasing the bit width is not worth their time, but assuming someone actually had this need, doing it right is a lot more complicated than it seems at first glance. --Again, this is admittedly another annoying "noodley point" but it could be important for someone. ASSUMING: The systems are most likely run in virtual machines, and the UID's are most likely the keys for a key-value store. Whether or not the UID are specific to just images, or are also used for other things (wall posts or whatever) is unknown. The first question is whether or not your key-value store can handle the increase in key length (UID). Since this is fixable, the safe assumption is "yes" albeit there might be undesirable (or even unsurmountable) performance penalties. A good PRNG is fed by a system entropy pool, and the pool is populated by various system entropy sources. Some believe virtualization can make the system entropy pool more predictable, but some believe virtualization can make the system entropy pool less predictable. It doesn't really matter which is true. The important point is if you can exhaust the system entropy pool, one of two things will happen; (1) the system will get bogged down waiting on the pool, or (2) a poorly written PRNG will start giving you less random numbers. Of course, "less random" is the most accurate way to phrase it, but in some cases, the actual result is the (faulty) PRNG gives you "predicable" numbers if the system entropy pool is exhausted. To do it right, you'd have to evaluate the frequency/pressure on the system entropy pool before increasing the key/UID width or you might suffer some highly undesirable effects. There are essentially two places where you might need to add hardware; (1) performance penalties of increased key width in the key-value store, and (2) performance penalties from exhaustion of the system entropy pool (with a well written PRNG). With the former you'd be paying for more servers, and with the latter you'd be paying for more entropy sources to feed the pools. I'm not sure how one would add specialized entropy source hardware in a virtualized environment, but with enough cost and effort, it might be doable (device mapping?). Needless to say, in either case or both, the costs could be prohibitive. The admittedly "noodley" point here is correctly maintaining a constant threshold level of entropy is occasionally easier said than done. Of course, in other cases, it might be brain dead simple to maintain a constant threshold. The only way to figure it out is proper testing. The non-power-of-two 136 bit length you mentioned seems interesting. I might be (incorrectly) reading more into it that is actually there, but I believe it hints at a far more cost effective solution, namely, just add more k-v stores. For example, the key/UID could only be 128 bits wide, and the extra eight bits indicate a particular k-v store. With the k-v stores being located "close" to the user, this could also improve bandwidth costs, usability/latency, and load balancing, in addition to the benefits of the CDN. I don't have a facebook account, so I can't check, but if there's some degree of predictability in a single byte (leading, trailing, middle, ?) of the UID, it would be further support of the above theory of operation. It doesn't need to be perfectly consistent, since at each location there are probably multiple k-v stores. Even on a collision of a generated key/uid in a particular k-v store, the UID might not be thrown out unless it was already used in _all_ of the local k-v stores. This would further reduce the pressure on the system entropy pool, but due to the need for replication/redundancy/backup, I seriously doubt this is the case. Though going from 128 bit to 136 bit (or similar) _is_ an increase of the width of the identifier, it probably has nothing to do with maintaining a constant threshold of entropy. It's probably just a smart business decision to reduce hardware/bandwidth costs. PLEASE NOTE: The above is only mindless speculation about how the 136 bit UIDs/keys might work, and (hopefully) no one at facebook will confirm or deny it.
Aegean 16y ago
I am surprised this is standard behavior. So if I allow user X to see my photos it means that user has a right to publish all my photo urls. It doesn't look good to me.
- skbohra123 16y ago
  Clearly this is something that that makes this issue even more dangerous.
- DrJokepu 16y ago
  How is that any different from being able to save the photo as a file and upload it to a free image hosting site? From a security point of view? Since it can be easily circumvented anyway, disallowing sharing static photo URLs would be the real "pseudo security", in my opinion.
  - tptacek 16y ago
    It's different because in this case if someone dumps all your photo links Facebook can in theory just assign them new random secret IDs, whereas if someone uploads your photos to a hosting site there's nothing they can do about it. In other words, from a security perspective, it is in no way worse.
jules 16y ago
Are passwords pseudo security too? They are easier to guess than a random url. That one is entered in a form field and the other in the url bar doesn't really matter does it?
- tptacek 16y ago
  It sort of does, since your browser knows that it needs to be carefuly with things you plug into password fields, and doesn't know that it needs to be careful with random URLs. But that's less of an issue with a hidden IMG tag.
- arethuza 16y ago
  People are unlikely to share passwords - they are highly likely to share links via email or IM.