< How to root a Motorola Atrix 4G on 2.3.4 | A Response to Seth Godin's "The Illusion of Privacy" >
1) 22seven is secure
Figuring out if something is secure is really hard. The current way the industry measures it is by getting a reputable company to perform an in-depth and broad security assessment. 22seven claim to do this in their description. However, none of the results are published, so as a member of the public, we have little to go on. Even then, security testing is a bit of a market for lemons; that is, unless you are an expert, you don't know if the testers did a good job or not. For me to take their claim seriously I'd like to see a letter of attestation from a reputable security testing firm at the least. Until then, we can't know.
On the flip side, I use tons of online services all day that don't even get around to claiming they test their stuff, let alone go as far as I described above, and so do you. But, these services don't want access to my personal financial transactions, limited power of attorney, and leave all the risk of compromise on me.
2) 22seven is safe because they use Yodlee and they are safe
This is the claim put forward by 22seven themselves as part of their security overview, and elaborated on by Simon Dingle. The problem with this is two fold. First, there are many possible ways in which 22seven could be modified in the event of a compromise to provide access to your credentials, even though Yodlee is secure. Paul Cartmel reminds us of the old security truism; that you're only secure as your weakest link. A simple modification of their invocation of Yodlee would be enough to get the job done. Even if you aren't targeting credentials, a disclosure of your financial transactions alone could be a serious breach. So, you need 22seven to be secure AND Yodlee to be secure.
Even then, the use of a third party, with whom I have no contractual relationship, in another country's jurisdiction (now the US gov can subpoena my financial details, yay) makes me uncomfortable. What recourse do I have to Yodlee if they are the source of a breach?
Once again, you do this all the time, so put it into perspective a little :)
3) Yodlee is safe, because they've never been breached in 13 years
If you refer back to point (1) you'll note that I didn't use "no past breaches" as a criteria for "secure". This is for two reasons again. The first is that detecting breaches is really hard. You need to have significant monitoring, and the capability to understand what the tools are producing to know if you are breached. Even then, the possibility of the attacker being smarter than your monitoring exists (and to bypass your average IDS, you don't have to be that smart). Second, having never been compromised could be as much an indication that nobody has ever tried as it could that the site resisted attacks. Even if it was rock solid till now, people make mistakes, and introduce new code with potential vulnerabilities all the time. The past is no guarantee of future success.
To be fair to Yodlee, at no point on their site do they make this claim. This was put forward by Simon in his article.
4) Yodlee's access to your bank account is a good idea
I'm paraphrasing heavily here, but it captures the general argument between 22seven (and supporters) and the likes of Absa. The claim is that Absa is being a stick in the mud and resiting the new wave of customer service possibilities. Commercials aside, I think Absa has a point here. Of all the possibilities for how 22seven could get your info, giving you banking creds to Yodlee has to be the worst. In fact, this is a solved problem. How do you think you accountant has been getting transactional information from Internet Banking into Quick Books or Pascal all these years? They export the stuff in OFX (open financial exchange) or QFX formats and import it into their tool. Better yet, PFM's that support this have been around for a while. I've been using buxfer.com for over a year with this method, and it works well, without me handing over full control of my bank accounts to a random third party (but you'll not I do fall prey to some of the problems I listed above re jurisdiction & the possibility of buxfer getting hacked). There are a ton of other options too, a client-side browser plugin that stores your creds and imports it into the site would be a use of automation that doesn't require credential disclosure. Here, let me draw a picture:
There seem to have been two responses from two banks, Absa and FNB. Absa's response was to block Yodlee's servers. I think it may be a bit drastic, but I certainly have sympathy for their stated objection to handing your creds over to a third party. FNB, on the other hand,
has responded by will be getting rid of their One Time Passwords (via GSM as a 2nd-factor-auth) on login, and relying on transactional ("confirmation") OTPs only. They contacted me to clarify that this was planned before 22seven and was not a response to it. I think this is a bad idea (outside of 22seven), and have asked (as a customer) that FNB retain login SMS notifications at the least (they will publish a log of logins within Internet Banking, but by the time you've found an illegal one, it's possibly too late). Hopefully they'll respond. FNB went on to clarify that login notifications will still be sent by e-mail, and that the audit trail published in the app will include both failed and successful logins.
This has happened before though, with Twitter and Facebook. Remember when you had to give sites your twitter and facebook credentials, and the problems that caused? They ended up building in OAuth and providing an API that caters for third party applications (and per-application permissions). This may the chance for the banks to start doing the same.
I'm not saying 22seven and Yodlee are ripe for hacking, nor that they are safe. I'm not even saying us not knowing they're safe should preclude their use given what you do with the rest of your online data. Unfortunately, you need to make the decision, but I'm sticking to my OFX export in the meantime and find the risk of disclosure some transactional data, should buxfer get hacked, acceptable compared with the benefits it provides me (for e.g. I moved bank after buxfer made it clear just how much I was paying). I'm also not joining in any name calling, I disagree with some of Simon and Paul's points and agree with others, but this stands as my opinion in the end.
Update: Modified the "Bank's Response" section based on feedback from FNB. Thanks for going to the trouble of contacting me :)