Why 22Seven is most probably, but not necessarily, safe

After reading one too many ignorant articles and tweets about how personal financial management startup 22Seven must be safe because Yodlee is safe and so on — I cracked. I banged out a bunch of tweets in quick succession with the hash tag combination #22Seven my #2c. The response was interesting, ranging from “love your work” to respected tech journalist Simon Dingle’s “How do you know I’m not a computer scientist? And why does that matter? Do you have to be a chef to know when food is good?”.

RELATED

Advertisement

I want Dingle’s tweet to be an entry point to this blog but firstly a disclaimer:

I have three friends pursuing this space: Zulfiq Isaacs — founder MoneySmart, Alex Melhorn founder of MyMoolah.co.za and Kenny Inngs, Technical Lead 22Seven.com. I believe I am unbiased and I wish them all unequivocal success. These gentlemen are all legends of the software development industry. I believe that proper money management is a problem that needs solving and that all three of these tools could have an immensely positive impact on people’s lives if used diligently.

But back to Dingle’s tweet and my concerns:

It is my honest opinion that it is highly irresponsible to blog that a financial services application is safe without significant expertise in the online security space. So while I don’t believe I am THE most qualified person to comment on the #22Seven security model, I have been writing secure software for financial services for 10 years and have passed many security audits. You can read the rest of my credentials in my contributor profile.

Dingle’s tweet was in response to the following: “#22seven my #2c — @Simondingle blogs it’s safe and everyone believes. #awesome– he’s a tech journo not a computer scientist”. I tweeted this after reading the article Dingle subjectively titled “Why it’s safe to use 22Seven“.

While the title is highly subjective, Dingle does go on to say he is only giving advice. He cites the way Yodlee “interfaces” with the bank and its impeccable track record as justifications for the security of the application. To me this is classic journalism unsubstantiated by technical facts. I thus wanted to write a slightly more technical post illustrating the factors that make up a secure application and also list some of the problems I have with the current 22Seven implementation.

Dingle could, for example, have said the following: “Yodlee uses a technique called screen scraping to interface with your bank. This technique relies on a software robot user logging into your bank account on your behalf and indexing your transactional data via stripping the transactions from the banking site’s html.” Doesn’t this sound both more accurate and also scarier? I find it interesting that Dingle chooses to gloss over this technique which is generally accepted as being less than ideal.

I’ve written about bots before. They are essentially powerful fake users that understand the composition of the html of your bank’s website and interact on your behalf with your bank. Of course with a secure banking site they must pass the credentials to the bank site to get behind the login screen and then scrape (read) the data that you normally read when browsing your transactions. The fact that they can pass a clear text password to the banking application means they don’t one way encrypt (or hash) the password. I have a fundamental problem with this. I’ll explain hashing and the significance a little later.

Once Yodlee has acquired the transactional information, the transactions are compiled into a single file — I’m told usually an Open Financial Exchange (OFX) format file. This information is then passed back to 22Seven via web services where the data is loaded into its database for storage and analytics purposes.

So let’s assume — for the sake of this argument — that Yodlee is as near to 100% safe as possible. What people, including these journalists, need to realise is that web application security is not defined by the sum of the secure components but rather the weakest link between these components. The weakest link could be the network, physical security (up to and including human access to database and infrastructure) and application security.

In this case, application security comprises the integration architecture as well as software architecture. This is nicely illustrated by a graphic taken from Yodlee’s own site. Regular audits by companies and organisations like SensePost, HackerSafe, Payment Card Industry (PCI) and the International Organisation for Standards (ISO) (in particular ISO 27002 information security standard) ensure that the policies and procedures are in place to keep the application, network and physical infrastructure safe and secure.

Figure 1: The key aspects that comprise a secure application as taken from yodlee.com

Transport Layer Security

If we look at the following graphic, a likely scenario for the flow of your username and password and the acquired transactional information is a follows:

1a) You enter your details on the flash application and they are transported to the 22Seven web services. (It is highly possible that the flash application talks directly to the Yodlee cloud based SDK — which would eliminate steps 1a and 2 and generate a transaction directly to the Yodlee servers)

1b) Probably does not happen but it is possible that 22Seven stores your details in its own identity store (this would allow them to use another provider if it wasn’t happy with the performance from Yodlee further down the line).

2) The username, password and pin are transferred to the Yodlee server and SDK.

3) Yodlee stores these details so that they can regularly load your transactional data.

4) Yodlee spoofs a human user with a “bot” and logs into your banking application. You will probably receive an OTP pin request which you need to provide (this will flow from the flash app, via 22Seven web services to Yodlee). Yodlee will use the OTP to get behind the login screen of the banking web application.

6) Yodlee has now built up either an OFX or CSV which is then passed back to 22Seven via web services for processing.

7) The data is loaded into 22Seven’s operational data store for processing and analytics.

Channels 1a, 2, 4, 5 and 6 are the channels of greatest concern because these transactions are outside the DMZ (demilitarized zone) of the Bank, 22Seven or Yodlee. I think it is safe, however, to say that the information that flows in these channels is asynchronously encrypted using a public/private key [most probably secure sockets layer (SSL) or transport layer security (TLS)].

Password Hashing
We would also like to believe that the username password data that is stored in either 22Seven or Yodlee’s ID stores is encrypted. We also know that Yodlee has to be able to decrypt the password, so that it can pass it on to the bank to gain access. Thus the policy and procedure around key (that are used to decrypt) storage becomes critical as any developer with access to the private key would be able to decrypt the passwords.

Why is it not ideal that a password can be decrypted? To explain this, I first have to explain how you would check a password with the original if you can’t decrypt the original. In a banking environment what normally happens to a pin or password is that it is passed through an algorithm that outputs a value based on that password. This output value is unique for the password and you can’t take the output value and reverse engineer it to get the password back (decryption). This is known as a hash of a password and only the hash is ever stored.

So when a person enters their password, the password is hashed and compared against the hashed and stored original password and if they match the password used in the login attempt is the same as the password stored when the user created their account. [As an aside: the hashing algorithms are complex and ensure there is no possibility of a collision (duplicate input that can have the same hash output)]. This is also why if you ever click on a forgot-password link and get emailed your old password, close your account — no application should be able to present to you your original password. In Yodlee’s case they need to be able to decrypt the password to present it to the banking application via the software robot — this isn’t ideal.

But we’ve already decided that Yodlee’s processes, procedures and policies ensure that the decrypt keys are safe and that they are thus safe.

Careless Code
In my career my team and I have had to pass many security audits. These security audits are carried about by companies such as Sensepost.com, a team of global hackers that rip your application apart and find as many security holes as they can. The results are often astounding and leave you thinking “how did they think of that?”. A typical SensePost error can highlight some glaringly obvious, yet often overlooked, security risks.

In one case, Sensepost used a tiny hole like an error log file that it has gained access to, to gain further access because it then starts understanding the application folder structure. It is essential that 22Seven pass similar security audits — I’m assuming it already has. I’m hoping to meet with Inngs to find out more.

Human Error
Possibly the greatest area of concern is that another banking application opens the site up to increased possibility of phishing. A great example is a tweet Dingle sent on the day of the 22Seven launch. He thinks he’s mentioning Christo Davel, the CEO of 22Seven, in his tweet about behavioural economics. Actually he isn’t. Would you believe he’s just mentioned another Christo Davel who works, of all places, at Nedbank? That’s how easily a human can make an error on a web application that costs you dearly.

At the launch of #22seven. @ChristoDavel unpacking behavioral economic principles that underpin the system.

This is probably my major gripe with 22Seven, I bank with Investec and I do my business banking with ABSA. When asked for my ABSA password on the ABSA website I’m only ever asked for a component of it, this could save me from phishing attacks as I would have to enter my password a number of times in a number of different combinations to give away my full password. But on the 22Seven website it asked for the whole password. This is completely wrong and what I would describe as a very naïve implementation. Very soon you’ll be receiving 22Seven phishing mail that asks you to register your full password — be careful.

Also on my Investec account I have to enter my pin using my mouse and the pin pad is jumbled up making it very hard for key logging software to register the pin I have just entered, again this is missing from 22Seven’s implementation.

Other Concerns
Futher to my security issues I’d like to highlight some other concerns

Terms and Conditions
This isn’t a note about security, it’s about 22seven’s terms and conditions. I have an issue with several points, beginning with point 4. I am not allowing 22Seven to modify my security credentials.

I don’t like point 5 — No, I am not granting you limited power of attorney.
I don’t like point 8 — apparently you can’t use a spider, scraper etc. on its site but Yodlee can use it on your banking site. This smacks of “do as I say not as I do,” and I don’t like it. In fact, if the banks added this to their Ts&Cs to block 22Seven imagine the outcry.

Conclusion
While I don’t like some of the mechanisms that 22Seven uses to load and acquire the data, including usernames, passwords and pins, the site is most probably very safe.

I would also like to know what security audits it has undergone? Does it also store banking usernames and passwords and, if so, how it stores this information and what standard key policies it has adopted?

To be honest, and yes I’m old school, I have more faith in an application that uses an enterprise identity and authorisation control software such as Tivoli from IBM. I also have more faith knowing that all of the big banks have dedicated security teams.

I do trust Inngs and his technical team, I believe we all need a mechanism to curb spending and change our spending habits, debt is a life sentence for most people, I’m just not ready to use the software in its current implementation.

A parting thought to all geeks
Please can we stop using Pi (22 over seven) in everything we do – it’s tragically iUnoriginal.

A parting question
If this venture is funded by the Enthoven’s (founders of Hollard Insurance) is the application completely unlinked to a financial institution? Or is there a massive cross selling opportunity waiting to happen? If so, I’m loath to pay R70 a month to use the tool — no matter how good it is.

Nicky Cornish

I’m loathe to pay R70 per month regardless of who funded it. Waste of time and money.

Nicky Cornish

I’m loathe to pay R70 per month regardless of who funded it. Waste of time and money.

http://wogan.me Wogan

So in 11 years of Yodlee’s operation, it hasn’t ever had a breach. In the last 10 years, I’m willing to bet you can find instances at every bank in this country where online banking security has been compromised, and money has been lost.

On the balance of it, Yodlee protects your information better than the banks protect your money.

Anonymous

Yes and in those cases the bank insurance would cover you and you would be paid out. This is exactly the point – if you lose money in an unrelated way, but you used 22seven, even only once, the banks will not pay out. Good luck.

If you want to see what the service looks like without signing up with your details, check out my review and screenshots at http://kwantozonke.co.za/2012/01/on-common-sense-and-convenience-22seven-reviewed/

http://www.facebook.com/profile.php?id=555496404 Anonymous

Really excellent post, thanks for that.

http://www.simon.co.za/ Simon

Thanks for all the attention Paul, I’m flattered.

Anonymous

Give it a rest. I hope you read this and take some pointers.

http://www.simon.co.za/ Simon

I’m not in the habit of taking advice from anonymous commentators. Why don’t you tell us who you are?

Anonymous

Who cares who I am? Fact is that you are just coming across as a total arrogant a$$. Use it/don’t use it.

http://www.simon.co.za/ Simon

I care who you are – because now you’re being abusive. And that’s easy to do when you’re cowardly hiding your identity.

I am not arrogant. I chose to post a humorous response here instead of reacting aggressively to what was a childish attack on my integrity.

Paul has written a fantastic article above. I agree with almost everything he has posted here and appreciate his deep research into the issues at hand.

What I take exception to is that he found it necessary to single me out in his article, which would have otherwise been excellent. He even chose to point out an error I made in a tweet – something that is possible to do to anyone. We all make mistakes.

You’ll notice that when I write articles I don’t single people out and attack them. It’s unprofessional and puerile.

When someone chooses to call me arrogant or an ass, I expect them to at least have the decency to make me aware of who is addressing me.

So do you have enough class to tell us who you are? Or should we stick to our assumptions? I make my opinions known in public, and I accept the ramifications thereof.

Anonymous

“We all make mistakes”
The entire point of the article!

Goodbye.

http://www.simon.co.za/ Simon

Yes, I made a mistake in a tweet, not my article, you cowardly douchebag.

All Paul has done is a terrible job of agreeing with me. I made it clear in my article that while 22seven is safe, your banks will forego fraud responsibility.

Security experts love putting forward theoretical reasons why a system could be compromised. And they play an important role in doing so. But you can’t overlook practical, real-world experience.

22seven isn’t the first service to work this way. There are many case studies.

Anonymous

Thanks for such an incredibly detailed, informative and insightful article, greatly appreciated.

http://www.facebook.com/rihan.meij Rihan Meij

Well written Paul, was interesting to read. Storing your pin in any other place than your mind, is opening another avenue for attack, and the point is not if or has it been breached, but it is now possible to breach.

Best Regards
Rihan Meij

Bryan Allott

Besides the hard-facts technical security implications, there’s also the “insider job”, the soft-facts and personal/personnel implications. Most security breaches are old-school and come from within. A disgruntled developer, a rogue employee, all biding their time, waiting for the user base to grow. Cha-ching. Sure, you might catch the bad guy in the end, but while you’re waiting to get your money back, you still need to pay rent…

http://www.facebook.com/profile.php?id=555496404 Anonymous

Thanks for the comment Bryan, this is exactly why I think
processes and procedures are as important as network and application security.

Richard

You should also remember that most US financial institutions only provide Yodlee API access to mostly read only bank transaction data. So there is little motivation by hackers to attack Yodlee data.

Are these the same awesome US banks that allowed the sub-prime crisis to happen? We should definitely follow their lead 😛

http://www.imod.co.za/ Chris M

Hi Paul,

What a wonderfully well written article, thank you.

I like the idea of aggregating ones financial “pockets” and formulating the information into visual representations and tangible metrics, but I can’t help but agree with Paul in this post – I would want to know what audits the software has been through as well as a lot more before I started pushing my banking credentials threw a new system that only has its word to go on – catch 22, need users and time to prove the security of the site, but to turn people into users, people have to see users and without users, people won’t become users.I don’t know too much about this service, has anything been said by the banks yet? Do the banks endorse it or recommend it at all?There is definitely potential here, but right now I’m with Paul.

http://www.imod.co.za/ Chris M

Hi Paul,

What a wonderfully well written article, thank you.

I like the idea of aggregating ones financial “pockets” and formulating the information into visual representations and tangible metrics, but I can’t help but agree with Paul in this post – I would want to know what audits the software has been through as well as a lot more before I started pushing my banking credentials threw a new system that only has its word to go on – catch 22, need users and time to prove the security of the site, but to turn people into users, people have to see users and without users, people won’t become users.I don’t know too much about this service, has anything been said by the banks yet? Do the banks endorse it or recommend it at all?There is definitely potential here, but right now I’m with Paul.

Dljhillman

Great article Paul.Seriously changed my look at 22seven.

moneysmart

Thank you Paul! from all of us at moneysmart.co.za team

Meredith Sayer

This is all very interesting, but there’s no way on earth I’d give my internet banking login information to anyone! I wouldn’t give it to the people who work at my local bank’s branch, let alone some independent company. How is anyone even considering this!

Personally, I’ve been using a desktop based system which Nedbank gives away for FREE! It’s an amazing program, that does everything described above (and more), but has one killer feature – it runs from my desktop, so there are no security risks whatsoever. It’s called Personal Money Manager, there used to be a link on Nedbank’s homepage, but I can’t seem to find it now. Pretty sure it’s still available on their site though.

Fred MacKenzie

Hi Meredith,

I agree, Nedbank’s tool is very good. If only they would add credit card support, then it would be far and away the most comprehensive tool on the market.

It’s still on their website, you just have to Google for “Nedbank Personal Money Manager”.

Fred.

Craig

“Also on my Investec account I have to enter my pin using my mouse and the pin pad is jumbled up making it very hard for key logging software to register the pin I have just entered, again this is missing from 22Seven’s implementation.” – Try google “form grabbing”. Present in the vast majority of password stealing trojans. It is scary that after 10 years of writing “secure” software for financial services you are unaware of some programming basics.