Monzo Labs: Export your data 📁

[uoldfield]

Would love to have data exported as a CSV - makes analysis much easier as data is largely in a format ready for processing.

[edzieba]

A little worried that the emailed link has no authentication. Email is fundamentally a plain-text transmission after all (effectively ‘back of a postcard’ unless you add PGP or similar on top), so anyone who snoops that link can access the entire data dump silently with no barriers.

[jonnyuk]

Have I misread how this is to work?

I would never have my personal data being zipped and sent by email - email is insecure and having my financial data lobbed about on email, for me is a no-no.

Could you not send a Push, with an authenticated/tokenised S3 URL (time-limited, set for say, 10 minutes from when the Push is accessed) which will allow users to download it from there within that time?

[gmclean]

And for everyone who wants more security there is one person who doesn’t mind.

At present it’s emailed, but I agree, a better more secure option would be welcomed for this!

[awjdean]

I would never have my personal data being zipped and sent by email - email is insecure and having my financial data lobbed about on email, for me is a no-no.

Aren’t you currently emailed a secure download link which expires in a few days?

You’re personal data isn’t actually on the email.

[redshift]

That’s correct. You get 7 days to download.

Although an expired link currently points you to an unstyled XML file. It’s still clear the request has expired.

[edzieba]

You’re personal data isn’t actually on the email.

But a URL to the data is, with zero authentication on that link. Effectively the same as being sent plaintext.

[awjdean]

I see what you’re saying, but I think having an emailed link which expires is fine if you need authentication in your Monzo app to send that link.

A potential issue with asking for PIN/fingerprint authentication from the email link is it could lead to phishing scams. I wouldn’t be super comfortable entering my PIN outside of a card terminal, ATM or my banking app.

However, I do think the current implementation could be improved from a privacy perspective:

• There should be a limit on the number of downloads allowed before you need to request a new link.

• The download link should expire after a shorter amount of time. I believe links are currently active for 7 days. 24 hours seems long enough for someone to download their data.

[edzieba]

but I think having an emailed link which expires is fine if you need authentication in your Monzo app to send that link.

It doesn’t matter that triggering the email is authenticated, the result is a link sent in a plaintext transmission medium accessible with no authentication. Anything transiting the internet unencrypted should be considered public, encryption and authentication are the only guarantees of security. Limiting the number of downloads or availability time does nothing to solve that and is pure security theatre.
Either the data export needs to be held behind an authentication prompt (e.g. the same sort of allow-access in-app trigger as used with 3D secure, or a one-time password delivered through the app, etc) or the dump should be delivered through the app for the user to then move manually (either through USB data transfer, encrypted fileshare, etc).

[awjdean]

It doesn’t matter that triggering the email is authenticated, the result is a link sent in a plaintext transmission medium accessible with no authentication.

Wouldn’t someone need to login to your email to access the email, which is a form of authentication?

Limiting the number of downloads or availability time does nothing to solve that and is pure security theatre.

Surely, if the number of downloads is limited to 1 then it is an additional security measure. If you request the email, then download the data a person who has access to the email would then be unable to download it themselves.

Limiting the availability time is also an additional security measure. If the availablilty time is 24 hours, your data is only vulnerable from an email account hack if the hack takes place within 24 hours of your requesting the files from Monzo.

Anything transiting the internet unencrypted should be considered public, encryption and authentication are the only guarantees of security.

From what I’ve read there appear to be three places where an email could be intercepted:

1. From the sender’s computer to the sender’s email server.

2. From the sender’s email server to the recipient’s email server.

3. From the recipient’s email server to the recipient’s computer.

Number 1 shouldn’t be an issue. I hope Monzo encrypt emails when they are sent from the Monzo “computer” which generates the email to the server which sends the email, since I imagine the process used is similar to the one used for the Magic Link logins.

Number 3 shouldn’t be an issue. You can check if your email provider has an encryted connection with your computer by looking at your address bar for the lock symbol. If your email provider does not provide encrypted connections (and, as far as I can, tell they all do) you should change email provider since any personal information sent form using that email provider is vulnerable.

If numbers 1 and 3 are not issues, then number 2 isn’t an issue if Monzo can encrypt emails that they send to other email servers, which I imagine they can to meet regulatory requirements for Magic Link logins.

NB: I’m by no means an expert in this, please point out anything I’ve got wrong.

Either the data export needs to be held behind an authentication prompt (e.g. the same sort of allow-access in-app trigger as used with 3D secure, or a one-time password delivered through the app, etc) or the dump should be delivered through the app for the user to then move manually (either through USB data transfer, encrypted fileshare, etc).

If I’m wrong about the above points and the current method does prove to be significantly vulnerable, then the in-app trigger sounds like the best solution to me - having to type a password is a pain and downloading the data directly to your phone then moving it across could prove troublesome.

[edzieba]

Wouldn’t someone need to login to your email to access the email, which is a form of authentication?

No, this is my point. Email is not a secure transmission medium. If it were analogous to postal mail, it would be a postcard. Any server between the originating server and your mailserver, and anyone viewing packets travelling between those servers, can read the entire contents of an email message. This is why download number or time limitations are meaningless vs. a man-in-the-middle who can access the link at the same time (or before) you do so.

STARTTLS is better than nothing, but it’s effectively a pinky-swear on the part of the sending and receiving servers to comply. If an email is sent and STARTTLS is not used (i.e. a perfectly valid transport and the standard for email, so it only takes one intervening relay or gateway to be the weak link in the chain), then by the time it has arrived in your mailbox and you see it was not encrypted during that portion of transit it is already too late and the data is public. Even with DANE it only takes one misconfigured or malicious server in the chain to ignore the request for TLS for plantext to leak.

[awjdean]

No, this is my point. Email is not a secure transmission medium. If it were analogous to postal mail, it would be a postcard. Any server between the originating server and your mailserver, and anyone viewing packets travelling between those servers, can read the entire contents of an email message. This is why download number or time limitations are meaningless vs. a man-in-the-middle who can access the link at the same time (or before) you do so.

Good point. However, time & download limits do provide security for cases where someone’s email account is hacked rather than their emails being intercepted.

STARTTLS is better than nothing, but it’s effectively a pinky-swear on the part of the sending and receiving servers to comply. If an email is sent and STARTTLS is not used (i.e. a perfectly valid transport and the standard for email, so it only takes one intervening relay or gateway to be the weak link in the chain), then by the time it has arrived in your mailbox and you see it was not encrypted during that portion of transit it is already too late and the data is public. Even with DANE it only takes one misconfigured or malicious server in the chain to ignore the request for TLS for plantext to leak.

Sorry if I’ve misunderstood (all the acronyms are confusing), but I don’t understand why encrypted email (as I described previously & repasted below) is not sufficiently secure.

From what I’ve read there appear to be three places where an email could be intercepted:

1. From the sender’s computer to the sender’s email server.
2. From the sender’s email server to the recipient’s email server.
3. From the recipient’s email server to the recipient’s computer.

Number 1 shouldn’t be an issue . I hope Monzo encrypt emails when they are sent from the Monzo “computer” which generates the email to the server which sends the email, since I imagine the process used is similar to the one used for the Magic Link logins.

Number 3 shouldn’t be an issue . You can check if your email provider has an encryted connection with your computer by looking at your address bar for the lock symbol. If your email provider does not provide encrypted connections (and, as far as I can, tell they all do) you should change email provider since any personal information sent form using that email provider is vulnerable.

If numbers 1 and 3 are not issues, then number 2 isn’t an issue if Monzo can encrypt emails that they send to other email servers, which I imagine they can to meet regulatory requirements for Magic Link logins.

[edzieba]

Sorry if I’ve misunderstood (all the acronyms are confusing), but I don’t understand why encrypted email (as I described previously & repasted below) is not sufficiently secure.

Short version: email is unencrypted by default, and any encryption added is voluntary and reliant on each server handling your email to agree to encrypt it for that hop. i.e. encryption can be requested, but cannot be enforced, and is not end-to-end.

[mmcow]

I’m not sure if this is the feature I’ve been using, because the file is generated on my iPhone and then uses the standard iOS share sheet to choose destination - no need for emails.

My change request is to be able to specify a start date. I’ve exported the data to MoneyWiz using the Quicken export filter, but that makes incremental data importing very difficult - you need to use an intermediate app to remove all the transactions that have already been imported or manually delete them one by one, which is completely impractical.

[awjdean]

It sounds like you’re downloading a bank statement rather than the “Export your data” feature currently available in labs.

Your post would probably be better off here:

Monzo Does Bank Statements

We’ve added the ability to create bank statements, I hope you’ll find it useful Full details here: And props to @jamesallison and @richmccartney for their work!