Ohhh, sorry yes I understand now. As I said, randomness isn’t a defence. You could write a program to systematically guess all user/upload ID’s
I will happily write you a proof of concept script later.
You do realise that your are asking for the impossible? If someone post an image that is not linked in this or any other thread, it will be linked in this or another thread from that moment onwards!
Or, to put it the other way around: Both images that were linked in this thread fulfilled your conditions until they were posted here, but obviously ceased doing so after they were posted here.
That’s what I had in mind.
Careful. Without Monzo’s (and possibly the other user’s) permission this could be interpreted as “Unauthorised access to computer material.” under the Computer Misuse Act 1990. (yes, I did some quick googling between my two posts.)
Then what exactly is the issue?
1 Like
How would you know which user is attached to which id?
1 Like
The issue is that this data isn’t protected. Someone who knows it’s there, and has the time and resources to guess the unique URLs (and maybe spend a bit more time to discover any “strategy” that is used to generate thes URLs to make your live easier) can find any image they want.
2 Likes
Proof of Concept. It would be in psudocode and I’m a penetration tester, I know the law 
That’s of course the 2nd part of any possible exploit. The point is: You should fix part 1 before part 2 is developed.
And given that using publicly accessible AWS buckets is a massive big no-no, and a large number of companies have been bitten in the behind by this over the last few years, the main point, really, is that any competent company should not do that in the first instance.
3 Likes
Yes. It’s not whether it is unlikely, but the fact this is personal data (under DPA) that is publicly accessible.
3 Likes
Good. Just saying, because I think someone might not be happy with “proof of concept” as they want the full exploit on a silver platter (just messing with you @anon4562461 Your questions are valid, in the sense that in and of itself this weakness is not on the same level as e.g. the Equifax one [but then, nothing is], but it’s still very serious, potentially a breach of UK data protection rules, and an entry point for an adversary. As such this is unacceptable practice and needs to be fixed asap.)
I hope you’ll follow responsible disclosure protocols?!
1 Like
Made a formal complaint, will draft email to ICO later.
4 Likes
1 Like
Woops. I seem to have opened up a can of worms but all in the spirit of making this product the best it can be.
4 Likes
Okay, I like my odds of 000098xxxxxxxxxxxxxxxx/xxxxxxxxxxxxxxxxxxxx-xxxxxxxx-xxxx-4xxx-xxxx-xxxxxxxxxxxx or 67 seemingly random characters - except that 4, suggesting there may be a pattern…
But I’ve just de-registered some attachments (i.e. removed them using the app) and those images haven’t been deleted. Will they be deleted by some retention policy?
Example removed image: https://s3-eu-west-1.amazonaws.com/mondo-production-image-uploads/user_000098cWeiXKbVsHsDZXY9/z2Hcro3wOGziy4FCOZv9-352c75cc-bc2b-4365-9747-f95012452c92
…Down to 51 characters I guess 
Be good to have some sort of official response from Monzo on this. It does worry that the any images I upload would potentially be accessible to anybody on the web.
2 Likes
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
Just as an additional response: Google Photos uses a similar system.
1 Like
91 bits (51 char) is still a good 8.34 million trillion trillion trillion trillion trillion trillion centuries, at 1000 guesses per second. That’s why I like my odds 
The odds are less good for my sofa or @crablab’s face. Short lived URLs is a good enough remedy.
Not sure what you’re implying?!
I’m not a massive fan of “good enough” but consulting with others apparently it’s within the law so 
I’m digging in on the deletion point I made (i.e. data retention), and going on the misconstrued basis that an app or something else may cache or store the URL, either for good or bad intent. Can you get your ‘receipt’ off the internet now?
I realise how low receipt image security needs to be, but handling the lowest priority data well is a good sign for the more critical stuff.
1 Like