Download receipts

(Hugh) #29

Yes. It’s not whether it is unlikely, but the fact this is personal data (under DPA) that is publicly accessible.


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 @Christophorus 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?!

(Hugh) #31

Made a formal complaint, will draft email to ICO later.



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.

(Gareth) #34

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:

…Down to 51 characters I guess :zipper_mouth_face:

(Dan Woodhouse) #35

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.

(Daniel Chatfield) #36

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.

Starling Discussion & Feedback
Starling Discussion & Feedback
Receipts security issue
Receipts security issue
Receipts security issue
(Hugh) #37

Just as an additional response: Google Photos uses a similar system.

(Gareth) #38

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 :wink:

The odds are less good for my sofa or @crablab’s face. Short lived URLs is a good enough remedy.

Receipts security issue
(Hugh) #39

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 🤷

(Gareth) #40

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.


It’s almost as if Monzo know what they’re doing and people just spout rubbish making issues out of nothing.
Good job nobody made an official complaint or drafted a letter to ICO.

(Hugh) #42

If no one did anything then there be rather more data breaches…

Also for reference, ISO material on responsible disclosure:

(Hugh) #43

Not necessarily, you can put quite a lot of sensitive information on an invoice…

Yup. Monzo currently do not implement signed URLs so once you publish that URL (or someone works it out…) it’s there for life.

(Gareth) #44

If you want an example of nothing turning to something, look at Tesco. Mixed content alerts lead to insecure passwords turning into Clubcard voucher fraud.

It’s some fun(?) reading:

I agree, exposed receipts is making something of nothing (unless one of the security questions on your account is how much did you spend recently). But that doesn’t mean you shouldn’t question why Monzo are doing something (and just assume they know what they’re doing).


I’ll all for questioning, especially when it’s a company I like. I want to know they’re doing things correctly. I take issue when forthright claims are made that something is a big issue and that an exploit could be knocked up in no time.
Especially when, even I, can see that that’s not going to be the case.

(Hugh) #46

Apologies for any offence caused


These ‘public’ images are most likely a lot more secure than most people’s password.

(Hugh) #48

Passwords are notoriously weak and actually, password rules (fixed length, containing these chars) make them worse!