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?”.

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.

Interestingly though, I’m not actually that worried about Yodlee itself — as Sam Perry, editor of Brainstorm magazine, points out:

Fast #22seven facts – your bank details go to 3rd party provider Yodlee – 11 years old, millions of customers, no security breaches. Ever.

— Samantha Perry (@samanthaperry) January 27, 2012

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:

Figure 2: High Level Component Diagram Illustrating Username/Password/Pin and transactional information flow

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.

5) Yodlee screen scrapes your banking application and processes the data.

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.

— Simon Dingle (@simondingle) January 26, 2012

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.