Posts tagged with “audit”…

Kublax insecure: what is going on?

Posted by Aidan, 1st May 2009. Share this:

• audit
• cto
• development
• security
• seedcamp
• turnaround

On paper Kublax sounds like a great start-up. They've set out to solve a real challenge faced by users of online banking. They're doing it with relatively little competition, are well funded, got through Seedcamp in 2007, have some really smart investors. What they're doing is a little tricky, although it's been done very well in the States by Mint, who are excellent.

I've been intrigued by Kublax's journey, having been following the space very closely. It was announced in passing during one of the TechCrunch Geek'n'Rolla presentations the other week that they were relaunching, seemingly without fanfare. Kublax had presented at the TechCrunch SeedCamp review event in September 2008, one year after getting funding, but were unable to show a working product.

Keeping it simple is as good a principle in business as it is in technology, much as it might make for glib analysis. Kublax' main priority was to address the pain they had identified: allowing users to bring their online banking accounts together for ease of use, better budgeting and to save money. Their main threat was that their implementation -- which by necessity requires the users to give up the online banking details they're not supposed to -- would need to be perceived as incredibly secure. Ease of use and security: that's it, a little mission statement for the developers.

Maybe the early roadmap looked a bit like this:

1. Build a prototype to explore the proposition
2. Raise some funding to pay third-party account aggregator
3. Building something easy to use and secure
4. Build a clever automatic tagging engine but also hire a bunch people to type in categorisations all day so that statement data gets correctly analysed
5. Start addressing shortcomings in service from third-party account aggregator
6. If it's working well, enhance the revenue generation mechanism and spend some money making the platform more robust, scalable, etc.
7. Profit

Something has gone wrong, however. Kublax is neither easy to use nor secure. That's a sweeping statement, so let's look into it.

Kublax is not easy to use

First off, it doesn't work properly in Firefox. At a quick glance, popups break and the budgetting table misforms. There's no tagging of transactions possible, no evidence that the interface learns, no statistical analysis from other users' general data, and poor initial categorisation of spend. I've put several accounts in it and less than 15% of spend gets categorised correctly, or at all. The interface is slow, counter-intuitive and fails to take advantage of a fair few Web 2.0 tricks that could really help.

The shortcomings from the third-party account aggregator haven't been addressed. The system can't recognise transfers between bank accounts, struggles with common direct debits, and can't figure out cash withdrawls in shops.

Take five minutes to log in to Mint. It's beautiful, and is based on the same technology. Yes, they raised around $16M more funding but it's a similar age and I bet it's not the technology that most of that cash has gone on.

There's huge potential in online account aggregation, but there's less functionality here than in Microsoft Money or Quicken.

Kublax is not secure

So what about security? Is Kublax secure? Well no, I don't think it is. There's at least one glaring security hole, and a huge amount of bad security practice to the extent that it is a good tool for hackers and phishers.

It goes without saying that making a secure product is fruitless if it isn't presented in a way that's trustworthy and secure. Getting that copy, branding and user-flow is essential to create the feeling of trustworthiness. Aside from SSL padlock icons in their browsers, most users have no idea whether what they're doing is secure or not, and the perception of security is emotional, and separate from any real security. The security FAQ is written in rather poor English with a liberal sprinkling of commas: "Kublax alerts can increase your financial security, by providing you with timely appropriate alerts". The FAQ includes this:

"What if my bank calls me to tell me that a robot is accessing my account and to terminate any account aggregation service? Have a look at your account and you'll see everything is normal. We do "read only" service and no transaction of transferring money can ever take place. Your bank has contacted you based on their misunderstanding of the way in which the service works. Put simply, there is no disclosure of your security details to us or to anyone else through your use of our service. [...] It is unfortunate but inevitable that in this modern age some of the older organisations find new services threatening because they do not understand the nature of the service or because the service may not show them in a favourable light in relation to their services or as against their competitors."

This reads like a phishing phone-call from Fonejacker's George Agdgdgwngo: "Good morning Sir, there is a pigeon in your bank account, I just need your bank account details". For a start, it's wrong. Security details do pass through Kublax and Yodlee, even if they're not stored. To suggest that the service is secure because it's not possible to transfer money suggests access to the read-only data is perhaps not so secure.

And anyway, it's not secure, with a cursory inspection showing up some really serious security flaws. Kublax has basic security errors including CWE-312 ("Cleartext storage of sensitive information"), CWE-311 ("Failure to encrypt sensitive data") and CWE-319 ("Cleartext transmission of sensitive information"). America's National Security Agency puts CWE-311 in the "top ten" most dangerous errors in the "insecure storage" and "insecure communications", and rates CWE-319 in the "top 25 most dangerous programming errors".

You can quite simply demonstrate all three of these errors by using the password reminder functionality. This sends your password -- completely unencrypted -- by email back to you, meaning that the sensitive data that Kublax do store is unencrypted and accessible by at least some of their employees. The message I received was:

"Dear ,

Your password for Kublax.com is PLAINTTEXTPASSWORD

Kublax Team. "

Oops! Awkwardly, when you use the password reminder functionality, Kublax doesn't confirm they've sent a reminder email. Rather, the site throws an error saying "You have been INACTIVE for a long time.Therefore for Security reasons we have logged you out".

That's not the full extent of the problems. Unlike secure sites, Kublax reveals the difference between an invalid email address and an invalid password as users try to log in. If you try to log in on Amazon, eBay, MySpace, Facebook, etc. and you get either your username or password incorrect, you'll get an error message telling you that one or both were wrong, but not identifying which. Would-be phishers with lists of email addresses to target for online-banking fraud can easily run their lists against the Kublax system to see which users are registered for online banking.

Having forgotten my own password for the system I tried about ten passwords before I got it right, and unlike secure online banking systems, Kublax won't lock you out after you try a number of incorrect passwords. This opens the door for brute-force hacking. Would-be hackers could easily look up the partners at Kublax's investors, for instance, and brute-force their email addresses. Even more dangerous is the face that the Kublax system has weakness CWE-521 ("Weak Password Requirements"), allowing users to choose passwords such as "letmein" or "password". There are good reasons for online banking services to restrict these choices.

Long-dormant accounts, such as mine which was last used six months ago, should probably be flagged as being dormant and require some form of additional security to reactivate, to prevent forgotten accounts being targets for hackers. There's no sign of this happening on the system.

With all of these obvious problems one rather wonders what the behind-the-scenes security of the infrastructure and back-end is like. It can't have undergone an external security audit.

What does all this mean?

From the outside, it's hard to see where it went so wrong. Other than having said hello to the Kublax team at the event in 2008, and having programmed using the underlying account aggregation software they use, I know little of the background. Some things are clear, though:

The technology implementation has been a disaster. The Yodlee account aggregator service that they use is not that difficult. In two weeks it's possible for a single coder to knock up something crude but essentially as functional as the Kublax site, and I know this because I've done so myself.

I suspect the problems have stemmed from a typical startup challenge: outsourcing technology is difficult for start-ups, and it's hard to get it right. I believe Kublax's technology is outsourced to India. Outsourced or not, there are a dozen Ruby on Rails agencies who could deliver a prettier, more intuitive interface than Kublax's for no more than £50,000, and in a matter of a few months.

And what next for Kublax?

A few tips from us:

• Take down the site until it's secure, and get an external security auditor in.
• Get in a new creative agency and brainstorm some designs with them. Look at Mint and some of their competitors for inspiration. Come up with a less clumsy way of integrating financial product referral: it drives revenues.
• Find a way to manage the capital outflow to the account aggregator. There's likely a massive burn rate for the business in this.
• If necessary, start raising another round of funding to buy some time.
• Get in a new CTO, and start prototyping an application with the new designs. Take that to the investors. The CTO should be cognisant that a highly productive web language will probably be more cost-effective than Java, but in a few months he should be able to catch up with the last platform.
• Don't forget SEO this time: it looks like an afterthought in the current platform.

A final comment

Reincubate are in the industry to build and contribute to growth start-ups. It's incredible that a Seedcamp winner should struggle so much with their technology, and we're always happy to provide constructive criticism and suggestions to move forward, as above.

There are valuable lessons to be learnt by other entrepreneurs looking to innovate in this field. Don't lose track of the consumer pains you're addressing, and if there's a threat around security, for instance, do everything you can to mitigate it.

As ever, we appreciate the feedback we receive.

EDIT: Interestingly, Kublax was tipped off about some of these security problems by Doug Winter back in February. He found a more serious security problem which has since been fixed, but concludes his review: "Kublax: security fail, usability fail and coding fail. If I were a VC who had funded this I would be quite upset".

JUNE UPDATE: No more than a month after this post we were pleased to see Kublax's new CEO announce an overhauled site which addressed some of these issues.

This post has 2 comments »

How to survive an audit or code review

Posted by Aidan, 26th February 2009. Share this:

• audit
• code review
• due diligence
• investor

It's not unusual that we're asked to evaluate a start-up's technology platform, often by their investors or potential investors. Many developers or agencies are taken aback by this and are ill-prepared to respond. Competent developers with repeatable, structured process and methodology should find that handling a code review or platform audit is not arduous.

First of all, developers should not be surprised by the prospect of an audit. We've written before about the challenges agencies face when serving start-ups as opposed to established businesses, and the two are very different customers. Funding a new company can be a risky proposition and there are many factors that will lead an investor to request such a review.

"Surviving" such an audit is simple, and there are three golden rules:

• Take it seriously. All businesses care about the money they're spending, but start-ups really care and their owners and investors will look for reassurance.
• Be prepared. Don't wait until the auditor shows up at your office: wasting their time whilst you prepare will not get the meeting off to a good start. If you have everything ready beforehand, that's great. If you're able to send them information beforehand (or after) it will help them compile a more accurate report. Most audits are relatively short, and it's exhausting work for an auditor to review and understand everything that's been done. Having key staff available for interview really helps.
• Be honest. If you don't have a swathe of documents that the auditor has asked for, that's fair enough. Just lay out what is available and they'll work their way through it.

For our sake, we will work on behalf of the investor or start-up, or can assist an agency in preparing for an audit where we have no connection with their client or client's investors.

Depending on the nature of the platform being built, we'd typically ask for and expect to receive the following information. Often remote access will not contractually be a possibility, so a visit to agency offices is routine and makes interviewing easier.

Planning

• A list of user stories identified for the project, split into:
• Developed stories (with completion date of each)
• Partially complete stories (with last-modified date of each)
• Stories not yet started
• If the project is not agile, a description of methodology and specification, requirements or work unit documents
• Any pre-sales or pitch documentation
• A copy of the release plan and the iteration plan
• Evidence of capacity planning, with key factors and variables

Documentation

• Visual module summary of components (should make factoring & any design patterns clear)
• Summary: How is the application tiered?
• Summary: How is persistence managed?
• Summary: Application hosting, with server and network topology and details of any cloud (like Amazon EC2 or S3) or CDN (like Akamai) used
• Any platform architecture documentation
• Unified modelling language (UML) or class diagrams to show to core of the application
• Data flow, sequence, state diagrams
• Database ERM/schema diagrams
• Metrics from code coverage tool (FxCop, for example)
• List of 3rd-party components used & licensing status of each
• Access to bug-tracking tool, or full report from tool against project
• A full report from whichever time-tracking system is used by the developers
• Service level agreements (SLAs) from any relevant hosting or service providers

Source code and infrastructure

• Access to SCM platform (SVN, CVS, VCS, SourceSafe, etc.)
• Copy of HEAD source from SCM, and each release branch
• Access to unit test source, results of a recent run of unit tests (access to any continuous integration tools like CruiseControl is a bonus)
• Access to artwork PSDs if appropriate
• Access to database schema creation scripts
• Access to live IIS console or Apache configuration
• RDP or SSH access to a pre-configured development machine with VisualStudio or other IDE

Authentication

• Project administrator password for source-code management (SCM) tool
• "sa", "root", "Administrator" and application-specific username & passwords for servers and database as appropriate
• Any .htaccess passwords
• Credentials for access to Google Analytics, Adwords and Webmaster accounts or alternatives if provided by another vendor

This is by no means a complete list and will vary according to the project. We'd be delighted to receive any feedback on this, and we'd love to hear from you if you're planning or expecting an audit.

This post has 0 comments »