Ok sorry, I hate to be a pain but I don’t think my question was clear. The relevant question is: how many other banks do users bank with - since each bank’s accounts can all be accessed using a single set of credentials - not: how many actual accounts do they have so…
0 voters
Including Monzo?
…
No. The assumption is that you’ll be accessing the other bank’s account’s data through the Monzo app so you’ll be using Monzo regardless. That means that having a Monzo account doesn’t increase your exposure.
Even so, surely one of your two banks being compromised is less bad than both?
Eurgh you’ve just made me realise that the original question’s irrelevant. What matters is how much money is in the other accounts not how many are breached. Oh well 
But as I’ve already agreed, all accounts (if your non-Monzo accounts have money in them) being breached would be worse than just your Monzo account being breached.
Nowadays that’s pretty irrelevant, it’s whether they’ve salted the hash function and are using something modern like SHA-2
(Edit: irrelevant as with JTR and some GPUs from AWS it’s trivial to brute force unsalted hashes. Most banks also have very restrictive password policies - 1 number, 1 uppercase etc, users are lazy so only meet the minimum and by feeding the policies into JTR it becomes very, very efficient)
I don’t mind this, but I’d prefer development to focus on Pots, Breakdwon etc, improving the Monzo current account before enabling me to view accounts which I use less and less.
The best implementation of aggregation was Egg Money and that says a lot as they flopped 10 years ago. No matter how awesome you are it is going to be loads of entering passwords, connection errors and long delays while your incumbent accounts load. It is the opposite of a monzo experience and I would be more than happy to wait for psd2.
I wouldn’t touch this until PSD2.
No, this would not be a good use of development time at present given the state of the current account and the missing functionality there.
Maybe in a few years.
As far as I can tell - yes - anyone in the EC.
One partner we’re considering has a great solution for this. They store the credentials encrypted, and we keep the encryption key on your device. It limits the scope of a breach to just 1 user, and attackers would have to break both the PISP/Aggregator AND your individual phone, and even then only 1 user is affected.
Hmm. On first glance, that sounds reasonable, but with security the devil is in the detail, so I’d want to see more detail and think about it a lot more. certainly sounds better than storing plaintext passwords though.
Ok, in my initial answer, I was clearly underestimating the ability for Monzo to not hold login details centrally, and more generally the thinking that has already gone into the security implications/limiting the fallout from a security breach. The more this thread has gone on, and Simon’s filled in details, the more I think I would use a Monzo aggregator service even if it wasn’t using an API for everything. Especially given:
I wasn’t previously aware of this, and the account I most want to view in the Monzo app is my credit card account. In a best case scenario, the data from it will be opened up using an API along with the bank’s current accounts, but if not, I would most certainly like to see Monzo come up with a secure, reliable solution to pull these data into the app.
One thing I think you will have to consider with a service like this, is the communication about it needs to be very clear (but concise!) to put people’s minds at ease over sharing login details, both from a security standpoint, and not breaking their bank’s T&Cs.
From the inception of this thread, I was a pretty hard “No” vote. This is something I really want to see but the security concerns push the desire aside. As things have gone on, however, I’m starting to teeter towards a “maybe” depending on how the security stuff pans out.
Apart from the fact that I still believe that the only one who is permitted to save passwords using any kind of reversible encryption ever is my password manger, the other problem with that is that you still need to share your password with someone. I have a fundamental problem with that. A password is used to authenticate for a given account, and for nothing else. Never share a password with someone else. It’s just that simple. (Although, even I make one exception to that rule for my wife, but there we go.) Also, never ask your users to share their password for x with them. It’s that simple. And I really think it is very irresponsible of any organisation to ask users to share their passwords. That is training them to fall for phishing.
Any org that asks users for their password gets immediately downgraded on my internal scale of trust. That includes Apple.
Incidentally, as I have outline elsewhere, Monzo doesn’t come across as being too good in security to me (2nd-last para), so that gives additional cause for concern.
I feel like legacy banks are good at making it feel secure because it’s nearly impossible for me to access my own accounts. I don’t think they’re nearly as secure as they seem.
Monzo has great usability and I’m not worried about their security at all. I protect my phone well because there is a lot of sensitive information on it, not limited to banking and I can still phone my bank to freeze cards etc.
I don’t believe this, not with RBS doing things like asking for specific characters of the password.
I think we all agree they should do this (ideally a slow memory-intensive password focussed hashing function like BCrypt that’s resistant to specialised hardware) but I don’t have a lot of faith.
There is a way to handle this securely with reversible encryption and some complicated hashing functions: cryptography - How do some sites (e.g. online banks) only ask for specific characters from a password without storing it as plaintext? - Information Security Stack Exchange
Why? Slow and memory intensive does not make it secure? MD5 is fairly slow and it’s completely insecure.
It’s still less secure than a hash that can’t be reversed, even if there’s a HSM involved. You shouldn’t be encrypting passwords with a symmetric cipher, I don’t care how complex your set-up is. There’s just no reason for it and it’s additional risk.
And yes, BCrypt being memory intensive and slower does make it secure. MD5 is a poor example comparatively, BCrypt was designed to be difficult to create specialised hardware to brute force passwords with and has a configurable cost to enable you to keep up with Moore’s law. Scrypt is also a good example here because it deliberately uses exponential memory.
Take a read of http://www.sciencedirect.com/science/article/pii/S0167926005000581 for example and you’ll see how people have implemented other password hashing functions with an ASIC. If you read up on the history behind BCrypt and Scrypt you’ll see they were designed to make this difficult.