Download receipts

I’ve been conversing with Hugh privately but for transparency I’ll cross post some of the info here.

It would not be possible for someone to brute force one of these URLs as they contain over 100 bits of entropy (this even excludes any entropy in the user ID or the UUID which comes from the client).

It would require more computing power than is available on the planet to brute force one of these URLs.

As mentioned in comments here, the ideal situation would be that the API would return short lived signed URLs. This additional measure as part of defense in depth would mitigate the impact of inadvertent disclosure of a link as it would only be accessible for a short period of time. It would also harden it against a misconfigured S3 bucket that enabled directory listing.

There are a couple of things that make rolling this out more challenging:

  • App caching (the apps would need to be significantly changed to reload these URLs from the API rather than relying on their cache)
  • Third party clients. The API is currently split into two, an API for uploading images and a generic attachment API that takes a URL and adds it to a transaction. These are currently completely separate (to allow third party clients to attach images that are hosted elsewhere). To roll out signed URLs the attachment part will need to be aware of the upload part.

I’ve passed this on to the partnerships team, they’ll be making a bunch of changes to the API and this is a good change to add to that list.

Some closing thoughts:

  • Everything that is accessible to a single person over the internet is theoretically accessible to anyone
  • Whatever the authentication method it is ultimately a sequence of 0s and 1s that allow one person and not another.
  • Any sufficiently long random sequence of 0s and 1s cannot be brute forced with the computing power available on the planet over a time period that doesn’t exceed the age of the earth.
  • So provided the randomness is long enough (which it is in this case), brute forcing is not a viable attack vector.
  • Additional security measures such as signing the URLs with an expiry provides defense in depth and would limit the impact of someone inadvertently disclosing a link to their attachment as the link would only be valid for a short period of time. However, in the absence of an inadvertent disclosure the attachments are secure.
19 Likes