Log in links now coming via SMS too

Is email the ‘long term’ choice for authentication? Are you planning to still use email for the full current account when it launches in 2017?

I hope they implement some sort of secure two-step verification code system that works similar to Google’s.

Indeed. Proof that I can access an email account shouldn’t be enough to provide bank account access. While it’s fine when it’s a pre-paid card in beta, you’d hope this will change!

While I appreciate it’s a bit of a security trade off, as my email is protected by 2FA and my phone by a 6 digit PIN, an SMS is more convenient I think anyway!

@RumeeAhmed

One thing that I’m currently working on (and intend to write a blog post on at some point) is our plan for authentication.

There is always a trade off between increasing security and good usability. We take a risk based approach that ensures you have the freedom to do many things from within the app but the authentication we require is proportional to the risk involved and thus you are not burdened with lengthy security processes to e.g. view your balance.

Your email account will contain many sensitive emails and also enable someone with access to reset the password on many other accounts. The impact of a malicious person accessing your email account is likely to be greater than the impact of viewing your transaction history, this is why we let you log in (but not send money) with email auth.

In the future we are planning to have a risk based authentication system, if you are signing in on a device that you’ve signed in on before then this is lower risk than if it is a device we’ve never seen before and in a part of the country we don’t believe you are in.

If you are signing in on a new device then you’ll be able to authenticate this new device from an existing trusted device. If you don’t have access to this device then again we may require further authentication before letting you in, depending on a variety of factors. Whenever you sign in we will send an alert notifying you of this with a “this wasn’t me” button that will put your account in lockdown.

Similarly, if you are trying to send money to someone you’ve sent money to before then this is lower risk than if you are trying to send thousands of pounds overseas. The authentication we will require will be based upon our evaluation of the risk.

I’m more than happy to answer any questions you have, either here or via email (daniel@monzo.com).

6 Likes

Thanks for the summary Daniel, it makes interesting reading.

We all know the pain involved in setting up a bank account for the first time, and most of us have had to live through multiple generations of sometimes maddening security methodology in order to use online banking.

I am really encouraged to hear Monzo is approaching this in an innovative way, while also being aware of the issues around using email as an authentication method for the more heavyweight actions, and I look forward to reading your blog post!

2 Likes

To have different options seems like good news to me. My email isn’t always as instant as I’d like, so having SMS as a back-up would be useful. However, when I travel abroad, I often use a foreign SIM card, so I wouldn’t want to have to rely solely on SMS.

Perhaps future integration of WhatsApp could be considered?

Hopefully, now 1.6.3 appears to have resolved the issue of logouts, this should no longer be such an issue anyway!

You know, we in the information security community have been telling our friends, families, colleagues, and clients “whatevery you do, don’t click/tap on links that come to you via email or SMS.” So having a bank that not only DOES this, but tells its customers “this is secure” is a bit of a pain. In fact, the Monzo app just told me it would send me a “magic” link (it’s words) that would log me in. This stuff isn’t “magic” and it’s also not terribly safe.

If your customers get accustomed to clicking and tapping any Monzo-looking link that shows up in their inbox, you’re setting yourselves (and them) up for highly effective phishing later on. Monzo customers will be especially susceptible to an email or an SMS that says “We’ve updated something, tap here to get the new app” or “there’s a problem with your account, click this link to login and fix it.” They’re going to click/tap because they’ve been trained to do that over and over by the bank’s legitimate communications with them.

Unless you’ve got some magic solution for phishing that the rest of the banking industry doesn’t have, this is a dangerous precedent to set with your customers.

2 Likes

Don’t forget we are talking about an email that’s sent instantly (even if it’s not quite arriving instantly all of the time at the moment) after the customer taps a link in the app to log in.

‘Magic’ is just a bit of fun, it’s a term borrowed from Slack (& others?) and to be fair, I’ve had colleagues tell me how amazed they were that they could log in through one of these links, rather than having to remember their password.

This approach does fly in the face of conventional banks who “will never send you an email with a link to log into your account” but as Hugo has already pointed out, managing security like the other banks is not :mondo:'s aim

this is an approach that’s being adopted by more & more tech companies.

Even so perhaps @daniel could comment on this particular risk? I agree with your comments about conditioning users to click the link & this is a bank after all…

Unless you’ve got some magic solution for phishing that the rest of the banking industry doesn’t have, this is a dangerous precedent to set with your customers

We don’t think trying to influence user behaviour is a very effective way of trying to prevent attacks such as phishing. Despite your best efforts, users will either ignore your advice or be tricked by complex scams. The burden of security should sit with us, and you should be able to click on any link you want without being defrauded.

We have mitigated the risk of phishing by removing passwords entirely.

The link via SMS is a temporary solution while we move email provider. Even so, I would like to present a counter argument to the “links are bad” statement. If, instead, we sent a 6 digit code then this could be phished - the user would believe they were logging into Monzo so would happily enter the code into the phishing site/app which would in turn send it to Monzo to log in. With a link, we can control where the code goes and we can channel lock it such that it is useless to anything but the instance of the app that requested it.

As with everything we do, we will continue to evaluate and iterate and be completely transparent - I intend to publish annual statistics on a range of things from levels of fraud to numbers of account takeovers.

9 Likes

This is a strange reply. The fact that the links Monzo sends are secure is completely irrelevant. I’m never talking about links sent by Monzo.

Phishing is about links sent to Monzo customers from bad guys. Monzo isn’t involved. Users utterly lack the ability to distinguish a legit email from a copycat email. It is irrelevant how secure the legitimate links are because the users are being trained to trust emails that look like they’re from Monzo and to tap the links inside. Maybe Monzo-originated emails are good ‘magic’, but my mother’s inbox is stuffed full of emails that are bad ‘magic’ that didn’t originate at Monzo. Users simply cannot tell the difference.

Imagine a bad guy sends your customers a convincing email saying “Monzo finally got our banking license! Tap here to login and give us your current account details so we can migrate you!” Your users are going to trust it. They’re going to tap that link and go to a really convincing looking web site. It might look just like the Monzo app. Bad stuff is going to happen. That email doesn’t come from you and it’s not going to your website at all. The first you’ll hear of it is when customers start complaining that they tapped some links that looked like Monzo links, only they got defrauded instead.

And how many phishing emails will they get for their other banks, online services, etc. and users willl think “It’s safe to tap Monzo links. So it’s probably safe to tap these links, too”. But they don’t know what’s a Monzo link and what isn’t. That’s why it’s not safe to tap any links: end users don’t know where they go or how to tell.

Security people like me are constantly whispering in your customers’ ears saying “never click or tap any links in any email—EVAR”. And our friends and family trust us, as well they should. But then this bank comes along and says “here’s an email: tap this link to login.” They’ll ask me “Hey Paco, my bank sends me links in email and says I should tap them to login. Should I do that?” And this is what frustrates me: I will continue to tell my mother, my partner, my children the same advice: “No. You shouldn’t.” And so will the rest of the security industry. We give that advice because with respect to every other email in their inbox (that isn’t a genuine Monzo email), that’s really sound advice.

I’m not sure you’re doing yourselves any favours picking this battle with the security industry. I’m not the first infosec guy to raise this, and I won’t be the last. It’s a distraction you don’t need. I want you to succeed, but you’re going to waste so much bandwidth and breath debating this over and over and over with people like me. There are so many secure ways to authenticate users that don’t contradict conventional wisdom. Picking one of them would let you get on with what really distinguishes your bank and quit arguing security semantics. Security people are really well-intentioned people who have broader interests than whether Monzo-originated emails are safe to click. Asking our friends and family to do something we’ve spent years teaching them not to do makes it harder on us and harder on them.

It isn’t relevant whether Monzo gets it technically right. It’s the end user who will suffer.

5 Likes

You raise some good points . To continue the discussion around this I’d like to break this down into a few different cases and then also discuss what you would propose.

A malicious actor attempts to phish a user’s Monzo account

I think we are in agreement that by eliminating credentials that can be phished we have mitigated the risk of this.

A malicious actor attempts to phish another account belonging to a Monzo user

I think it is important to make the distinction here that we only send these emails when the user has explicitly requested it, just like password verification/reset links that users will be accustomed to from the vast majority of websites.

I can see that there is an argument to be made that even though we only send it to users when they request it, they will still attribute an increased level of trust to links they didn’t request. I don’t personally believe this would be significant as users already regularly have to do the same thing for password resets and email verification. I believe there is a cognitive difference between trusting something you requested and something you didn’t. If I phone my bank and ask them to call me back then I’ll trust this call where as if my bank calls me out of the blue then I won’t. It’s also important to note that customers will only have to do this a couple of times a year (whenever they get a new phone).

Any person who uses the internet clicks links all the time, I think the message should be to not attribute any more trust to links from an email than links from anywhere else.

For context, some other services that use links within an authentication flow

  • slack magic link
  • dropbox magic link
  • auth0 magic link
  • any website that has an OAuth flow

Other proposals

There are so many secure ways to authenticate users that don’t contradict conventional wisdom.

Always open to some concrete suggestions.

5 Likes

Great point from @daniel - The email only comes when you have specifically requested it. It’s very clear that that’s the case. Important to keep that in mind.

1 Like

Something I’m thinking about here and would love to throw in to the mix, I know that there are session tokens that mean only the application that requested the link can use it but how could a user verify that they are clicking on the link that they requested just then?

From a security standpoint, it wouldn’t matter because the link would be unusable but thinking the other way, from the recent logout issues I have an inbox full of login emails that are all indistinguishable to a regular user. My Mail app would always open to a Monzo login email but I never could tell if it had opened to the latest one or a previous one. I’m also thinking of a situation where I’m trying to login to the developer site, my iPhone and Android device, perhaps while a friend is trolling by typing my email address in to the login field on their own device. How could I work out what link to open where?

Unlikely to happen to the average user and an edge case that’s happening due to bugs elsewhere, I’ll admit so I’m just throwing it out as a possibility.

My proposed solution would be to make the emails a little more specific. Mention where the request came from in that “Tap the button below on your phone to log in to Monzo” string (I’ve noticed that it says phone even if it’s the API playground), maybe further details down below the button along with what to do if it isn’t you requesting.

Additionally, some kind of human readable session token in both the app and email would solve problems where I’m clicking an old or expired link. Allowing me to match what link the app expects with the received email I’m using. This could be a series of numbers, glyphs or pictures, words, anything.

There’s a fun story where my grandparents were trying to set up internet banking on an account, to do so they required a code from a letter. They ordered one, it didn’t arrive within the specified two days so they ordered another. The first one arrived the next day. They attempted to use that one but it had been invalidated by the second so a third code was ordered. In doing that, it invalidated the second code that arrived the next day. With the second code not working, support ordered them a forth code, the third arrived next day but had been invalidated by support’s forth code. This went on for weeks before I broke them out of the cycle by having very nice words with phone support to put through a manual activation (yay minor social engineering, they read me out the password and I have no trust in them now).

It’s a silly story but I can see it happening on a much tighter time loop with email. I nearly did it myself a few weeks ago before realising what was happening.

Not the usual security concerns I know, would just like the experience there to be better. Apologies for the long post that’s probably full of typos and might not make sense later, sleep is required here. :sleeping:

4 Likes

My proposed solution would be to make the emails a little more specific. Mention where the request came from in that “Tap the button below on your phone to log in to Monzo” string (I’ve noticed that it says phone even if it’s the API playground), maybe further details down below the button along with what to do if it isn’t you requesting.

Completely agree, that’s on the to-do list.

Additionally, some kind of human readable session token in both the app and email would solve problems where I’m clicking an old or expired link. Allowing me to match what link the app expects with the received email I’m using. This could be a series of numbers, glyphs or pictures, words, anything.

I’d like to solve this by a) telling you in the app when you click on an expired link and b) putting an image in the email that changes when it has expired such that it will have a red bar or something saying “expired” (assuming the mail client hasn’t cached the image). Your idea is interesting though and definitely one I’ll explore.

3 Likes

Hmmm. Some comments inline:

A malicious actor attempts to phish a user’s Monzo account
I think we are in agreement that by eliminating credentials that can be phished we have mitigated the risk of this.

I’m not sure you’ve eliminated everything that can be phished. When a user gets a new phone, how do they move their monzo account to it? How do you distinguish betweeen “my old phone died and I’m setting up a new phone” from “I’ve just phished the user and I’m setting up my phone to access their account?” What will the legit user bring to the table that a phisher can’t get? Assuming I can get whatever email they use for Monzo, what is the thing I need to phish from them to set up my phone to access their account?

A malicious actor attempts to phish another account belonging to a Monzo user
I think it is important to make the distinction here that we only send these emails when the user has explicitly requested it, just like password verification/reset links that users will be accustomed to from the vast majority of websites.

Are you saying that users will think to themselves “I didn’t request that link. I won’t click it”? That seems unrealistically optimistic.

Banks change their mind all the time. My retirement funds were invested at a bank whose login web page used to show me a special image that I had selected. For years they said “Never type your password unless you see your special image.” Then one day I went to login and their official web site said “We’ve done away with those images, go ahead and type your password to login.” It was legit. The bank had genuinely changed its mind about the utility of those images. (Rightly, they add little to the security of logins).

My point is that we can’t rely on a principle like “We’ll never mail you a link to click on unless you requested it” into the security regime. That’s wishful thinking. Marketing will want to send people stuff that tells them to click on things. So the “I didn’t request it” principle isn’t useful.

If you go back to Saltzer and Shroeder’s 1974 paper on security design principles, an important one is “psychological acceptability”. I would argue that we all know that more secure things are harder to use. We WANT our bank to be more secure than a garden variety web site. We know that greater security comes with a usability tax. Not only do we accept that tax when we’re talking about the bank that holds all our money, the difficulty gives us some assurance psychologically that “it’s not easy to get my money”. It isn’t a comforting thought to me to think that my money is as easy to get as my Dropbox documents.

Let me give a final example. Years ago I was working with a big banking network. They were asked to accredit some WiFi-based point of sale terminals that accepted credit cards. These PoS boxes did really strong end-to-end crypto. The devices, however, lacked any ability to do WPA or WEP or join any password-protected WiFi network. For a merchant to use these terminals, they had to put them on an open WiFi network. The bank was reluctant to accredit the PoS terminals because running open WiFi networks is unsafe. The PoS vendor was saying “but we do everything right!” The PoS vendor was correct: sniff their traffic all you like, you’d never do anything to the transactions. But the bank is worried about the merchants’ big picture, not just the PoS terminals but the fact that merchants will have open WiFi networks. Merchants will probably put other things on that network (they’re not gonna run 2 and 3 WiFi networks at the local newsagent) and the other things are not as secure as these uber-crypto PoS terminals.

Monzo is the PoS vendor from my story: it’s not enough that you do everything right. Telling customers to do dangerous things because their bank is secure is a bad idea. Telling people to turn on remote image loading in their email client because Monzo does things right is dangerous because their email is stuffed full of bad emails trying to abuse remote image loading. Telling people to tap on links to login is a bad idea because they’ll get comfortable doing that and will tap on other, insecure links.

It’s not that I doubt the security of auth0 links (thanks for that, I learned a lot). It’s that using them causes users to get used to tapping on links in emails for very security-sensitive things (like banking). And all the flipping from mail to Safari to app store will seem normal to them. But that’s what malware does, too. And they’re not gonna notice when they’re being attacked, because the attacks will look just like ordinary stuff their bank does. And the bank says it’s secure.

2 Likes

Your concerns sound perfectly reasonable, no doubt Monzo’s user’s are being targeted by phishing attacks and some of those will succeed. In my opinion though, it’s likely that the successful attacks will have got past users who don’t understand the security risks of clicking links (in emails or elsewhere) anyway.

And even if Monzo changed it’s verification method, other companies wouldn’t so trying to teach users not to click links (in emails or elsewhere) does seem a little futile. The only reason why Monzo’s links are ‘worse’ is because they’re being used for authentication. But the authentication emails are only being sent when they’re explicitly requested - people will make the association between emails they request & safe links, not just all links.

While this information

will only be published annually, Monzo will obviously be keeping a close eye on the number of account breaches that users experience & if that’s higher than average I’m sure the approach will be changed.
In the meantime, personally, I would prefer to use magic links because I’m confident that it’s not going to decrease the security of my account.

Can we opt out of this? If login links are sent via SMS, then the security on my bank account is only as good as my mobile phone company’s security, which is generally pretty poor. It’s all too easy to hijack someone else’s mobile number and get their SMS messages. NIST in the US has recently recommended against using SMS for two-factor authentication for this very reason. Your login method requires a secure and verified channel between you and the user, and SMS isn’t good enough for that. (Email is also a bit dodgy, but at least there are things I can do to secure my own email, even if most of your users probably don’t.)

1 Like

:eyes: