Continuing the discussion from To Use Monzo On More Than One Apple Device:
There is inconsistent behaviour in session management and authentication. See above topic discussion for more information. This appears to be a security vulnerability. All methods/channels for accessing an account should have the same level of protection - a weakness in one would otherwise undermine the others.
I’m not sure I would call this inconsistent from a security perspective, it appears to me that the Monzo app on iOS and Android use two different application identifiers when talking to the Monzo service (good for many reasons). If the service is enforcing only one valid session token per application, per user, that would make perfect sense.
The behaviour does appear inconsistent from a user side when you assume that a phone is a phone, no matter what OS it is running.
Ideally, the end goal could be something like Google do with their account system and track many logged in devices along with their last activity, allowing the user to revoke tokens for ones they don’t use anymore. Until that happens, I don’t see much wrong with this half-solution for now.
Thanks for continuing the discussion, your inputs are very valuable on all the topics.
From a risk point of view, if there is a requirement to limit sessions per app, then allowing multiple sessions per account is less secure. I don’t develop mobile apps, but maybe it sounds like some OS-specific session management is being used (instead of controlling this server side), but for some reason the implications of that for holistic system security hasn’t been addressed (yet). [Other orgs often suffer from this sort of security issue between apps vs. mobile websites vs. desktop websites vs. call centre - they all need to be “as secure”]
If you could use two OS-identical devices concurrently, the mixed OS device issue might be assumed to be intended behaviour. But that’s not the case. Either way it is a security vulnerability whether the behaviour is intended or not. Monzo might be happy to accept the risk of concurrent sessions, but it has already decided that doing that on same OS devices is not acceptable (currently).
The reason is to prevent a bunch of orphaned access tokens existing. Clearing all sessions from the same client when you log in is a convenient, although imperfect, way of achieving this.
It is not a security issue at all.
I created my company’s auth systems in a way which happens to work exactly the same way, for exactly the same reason.
Sorry to disagree, but session management is an aspect of information security. And information security is (SANS Institute):
Information Security refers to the processes and methodologies which are designed and implemented to protect print, electronic, or any other form of confidential, private and sensitive information or data from unauthorized access, use, misuse, disclosure, destruction, modification, or disruption.
Then,
I can’t believe that Monzo would be so sloppy that (session management) security requirements are defined accidentally via the consequences of an implementation choice for some other functional requirement.
But this issue isn’t about “same client”, it’s about “same account”, and hence cross device, including cross-OS.
The inconsistent behaviour might be a “design flaw” rather than a “bug”, but we don’t have a “design flaw” forum category. But it is certainly a security vulnerability.
Please provide an example of how you could perform an attack via this vulnerability.
Well, I am guessing because I don’t know what can be done on all versions of the apps, and how it is linked at the back end. It’s really up to Monzo to look at their own systems and data architecture, and do a risk assessment! But here are some initial thoughts to help with those discussions. Hope it helps.
The question is whether concurrent sessions are allowed or not. Currently the answer to this is both yes and no. So the current situation is perhaps due to one of:
NB Importantly I am only discussing Monzo here - I think it is inappropriate to discuss any other organisation’s apps here.
Various parties can be affected by breaches of confidentiality, integrity and availability. They include Monzo the company, its customers, its employees, its shareholders, its partners, its suppliers, Card companies, the banking sector, and even society. In this case I think the threat is primarily against customers, but there could also be a knock-on reputational loss for Mondo.
So, assume a customer loses their phone or it is stolen from them. They are alert and grab the nearest tablet (or the phone of a friend) to temporarily install the Monzo app , so they can freeze their card. The problem is that with a long session timeout (never?), if the phone and tablet use different OSs, the lost/stolen phone could still continue to be used to:
The latter could be used by a malicious person to try to recover full access to the account and card. I don’t actually really know what happens when you freeze your card, so the above are guesses - but anyway a stolen device might be used before the real customer notices and gets round to freezing their card. [I am assuming that freezing the card on one OS freezes it on the other i.e. it is not device specific, unlike this session management issue]
Thus, a Monzo account holder who uses apps on iOS and Android, is at greater risk of account misuse, than a user who only ever uses a single OS. Perhaps some customers assume that setting up the app on another device terminates their previous session(s) on other devices. That’s the impression that we have been given previously and only through some helpful dialogue via the Community Forum did we found out that this wasn’t necessarily the case. And that increases the possibility a lost/stolen phone with an authenticated app remains active.
Also, this highlights another closely-related security vulnerability, there is perhaps no way for the customer to “log out” of the lost/stolen device?
It could also be a security mandate failure e.g. contrary to a compliance requirement. I don’t know whether any systems accessed using this session handling are within Monzo’s current scope for PCI DSS, but if they were, then this would be an issue to be reviewed under “PCIDSS 6.5.10 Broken Authentication and Session Management”, and perhaps also “PCIDSS 6.5.6 All ‘high risk’ vulnerabilities…”. In the latter case, as outsiders we don’t know Monzo’s process for ranking vulnerabilities, and thus whether it is ‘high’ (PCIDSS 6.1).
No idea whether this issue also affects use of the API, but that would be another area to check.
Maybe concurrent sessions are meant to work, and Monzo has other security controls in place to prevent, detect and recover from misuse, but that isn’t how the same-OS version works. If the decision now or later is to allow multiple sessions, consider:
There are lots of risk-mitigating options available!
Lots of possibilities, but as I say, let’s leave it to Monzo to decide.
If Monzo chose to allow concurrent sessions it is a rubbish idea if limited only to fingerprints and not passwords (I appreciate you did not say that), as not all devices have fingerprint readers and not all people can use them perhaps due to clinical impairment or occupation. No reason not to have concurrent sessions with any chosen security be that password, pin or a finger, should you chose to permit concurrent sessions.
While you are focusing on concurrent use in this thread, there are many users who do not want to use it at the same time on two devices but be able to use it on either device as and when they see fit without use of one un-validating the user from their other device, so they have to then re-validate again when they switch to their other device, perhaps alternating between them multiple times a day. This was the reason for the original discussions on multiple device use.
I don’t think allowing multiple log ins is a real issue/the issue here. The issue here is not being able to deauth other logins from the app, and not being notified when someone logs into your account
If I could make a suggestion - I don’t think anyone who’s outside the Monzo team is in a position to fully understand the risks, safeguards in place & likelihood of a security breach as a result of this ‘vulnerability’.
The issue’s been raised & Monzo are aware of it (they were already) so I think we can leave Monzo to take the appropriate action to ensure that our accounts remain secure. At the end of the day, they’re liable for security here so I’m sure that Monzo have & will take whatever steps are necessary to manage this.
There’s no harm in talking this through but I can’t see any obvious benefits that could come from continuing to discuss this.
Yippee. Yes. Totally agree. All I wanted to do was report it 
The main problem this creates is that the Mondo apps are not trusted any more than any other OAuth client. They are functionally pretty much identical to the OAuth clients which developers can create.
Making it log you out of all other apps would mean that you’d also be deauthenticated from all OAuth apps you have connected. This would of course be quite undesirable.
Most likely the best solution is to never deauthenticate you from any app when you log in/out, but to provide a list of the places where you’re currently authenticated so you can remove old devices/apps.