[thom_nic]

Github does something similar, if you drag an image into the textarea in their issue tracker, it uploads the image to (I think) a public URL. I've considered what this could mean for teams with private projects who might e.g. attach screenshots with sensitive information.

Here's an example of an image uploaded via the GH issue tracker. Definitely public.

https://cloud.githubusercontent.com/assets/95562/7319912/200...

[sebak]

The problem is not with having public urls. The problem is with public urls that don't have enough random numbers or if these numbers aren't generated by a CSPRNG.

[arethuza]

Doesn't help how complex your URL is if legitimate users can pass it to anyone else who can then access the file without proper authorization.

[mikeash]

Preventing legitimate users from sharing the data with malicious users is essentially what DRM is, and as we all know DRM is never perfect and rarely any good at all.

It's much more important to prevent malicious users from being able to access these files without the help of legitimate users. Which seems like an obvious thing to do, but it's what Slack has failed at here. It's impossible to tell from that one GitHub URL whether they get this right or not.

[heydenberk]

It does help. Malicious users intending to share files can do so without having a public URL.

[willvarfar]

The good news is that github puts a uuid in the url, so its unguessable.

Slack, on the other hand, didn't have a big unguessable number... they had a very small number you could brute-force.

[mikeash]

Careful, being unguessable is not one of the properties required of a UUID. All a UUID guarantees is that two UUIDs generated by the specified procedure will never match, even if they're generated by different computers not in communication with each other. But it does not guarantee that an attacker cannot generate the same UUID generated by somebody else if they follow a different procedure.

It's the difference between avoiding collisions between cooperating entities, and avoiding collisions from malicious entities.

For example, a version 1 UUID is just the combination of the computer's MAC address and the current time. This is sufficient to guarantee uniqueness (as long as you don't duplicate MAC addresses, and you wait at least 100 nanoseconds between generating successive UUIDs) but will be pretty easy to guess if you have a rough idea of when the UUID was generated and which manufacturer might have made the NIC on the machine where it was generated.

More abstractly, a version 4 UUID is just a couple of identifying bits and 122 random bits, but the nature of the random bits is not specified. Your UUID generator may well use a PRNG that is not cryptographically secure, which could still be good enough for cooperative uniqueness, but not good enough to avoid predictability. (For example, a PRNG seeded with the machine's MAC address and boot time would fit this.)

In short, don't rely on a UUID being secret unless you know exactly how it's being generated, all the way down to the underlying random number generator. And if you're going that far, you might as well just read 16 bytes from /dev/random and be done with it.

[willvarfar]

The github sourcecode is not open-source, but they've open-sourced a lot of other code in which they seem to be using Ruby's `SecureRandom::uuid()` function in the same kind of context for generating what they term 'opaque ids'.

[BillinghamJ]

UUIDs are (usually) generated in a systematic fashion, so large parts of them are often possible to determine ahead of time.

[gruez]

Not in guid v4

[mikeash]

Unfortunately that is not necessarily true, as nothing requires a UUIDv4 generator to use a cryptographically secure source of randomness.

[MichaelGG]

What popular implementations in 2015 are using the braindead UUID generation methods?