KashFlow knocked by blog furore

An internet row broke out on Friday around the web-based accounting application KashFlow. John Stokdyk reports.

Allegations of security holes, a fog of technical confusion, name-calling and a wide-ranging examination of the issues surrounding software as a service - the great KashFlow API fracas has it all.

At the centre of the controversy is AccMan blogger Dennis Howlett. Last Friday, Howlett reported his shock at learning from CloudAve about a third-party security add-on for KashFlow called KashGuard.

“I had to read it several times, rub my eyes, swig a cup of tea and then lie down,” Howlett wrote in a post entitled KashFlow’s security nightmare.

The source of his incredulity was the discovery that KashFlow only had a single level of user security, and no capability to set access controls for other users. KashGuard plugs into KashFlow’s application programming interface (API) and you the ability to set permissions and restrictions within KashFlow itself.

In Howlett’s view, the combination of KashFlow’s single security level and open API opens the door for third parties to take control of the program. He raised some worrying situations the blanket log-in could permit:

  • A accountanting junior checking adjustments made by their boss would be able to change the data, rather than just review it.
  • A user experiences a problem when using Kashflow and KashGuard - where would they point the finger?
  • A temporary user with access to the system would be able to change bank details (and then change them back a day or so later): “Who would notice?
  • A hacker with a keylogging program could get between Kashflow and KashGuard and gain control of the application at the detailed level.

Howlett also speculated (in somewhat more lurid terms) that by allowing a third party to have this level of access to its core application would undermine KashFlow’s business model.

Howlett took the matter up directly with KashFlow founder Duane Jackson, who initially replied that Howlett was missing the point.

“We’ve not ‘created’ anything,” Jackson commented. “Certainly not a ‘security hole’... [KashGuard developer] Atlas have no special access to KashFlow that others don’t have. For a KashFlow customer to use KashGuard they need to give the KashGuard app their login credentials, enable the API within their KashFlow account and permit the KashGuard servers to access their account via an encrypted session.”

KashFlow’s decision not to add sub-accounts with definable permissions was based on the low level of demand for such a facility among its target users, who were generally small one-man bands, he added. Jackson accepted Howlett’s suggestion that KashFlow was limiting its market, but responded: “That’s a commercial decision on my part to have our team working on other elements of the system that I feel will be of more benefit to the business and more desirable for our customers.”

Howlett, Jackson and CloudAve editor Ben Kepes debated the implications of the situation extensively with AccMan readers including AccountingWEB.co.uk contributor Richard Murphy, CODA’s David Turner and Sunir Shah, “chief handshaker” of online accounts developer Freshbooks.

Continued...

» Register now

The full article is available to registered AccountingWEB members only. To read the rest of this article you’ll need to login or register.

Registration is FREE and allows you to view all content, ask questions, comment and much more.

Comments
dahowlett's picture

Gr8 pity

dahowlett | | Permalink

...you called up KF but didn't bother to request my side of the debate (John - you have all my phone numbers) ...Hey ho...not a problem but unfortunate...in fairness @duane doesn't get to speak for me but if you choose to quote without checking then fine - but please understand those are not MY words. In the meantime I will pursue this debate as part of a quality provider differentiator in the context of saas/on-demand/cloud computing. Whether anyone likes it or not it is an issue that firms see as relevant to their business. Sheesh....you all can do a lot better...but if not then expect potential users to wonder what the heck you're talking about. In the ,meantime, please check with peeps who know their stuff - that's what I did. As is evidenced in comments that KF chose not to address....

Kashflow getting flack! Who else suffers from bloggers vendetta

lerryn | | Permalink

As a newly committed integrator to Kashflow, we have just completed the integration of MyPAYE with KashFlow. We deal with one of the most sensitive areas of business, SaaS payroll and HR, where data security and access is fundamental.

Anyone reading the blog would get the impression that KashFlow had blatantly ignored security on their product and API, whereas I believe they have taken a sensible approach for their target market, the typical small business (Plumbers, Driving instructors and other brave people of this ilk going it alone in troubled times) who may have one or two employees. Few if any of these businesses would want multi-user access, or want the complication of setting this up.

We understood the vision of Duane and the Kashflow ethos and still chose to integrate the MyPAYE payroll with KashFlow. If we had the slightest doubt of the software security or the personal integrity, we would not be involved. We are delighted that the API is both open and has practical security measures. No-one can access a KashFlow account unless the account user specifically enables the API and the API access can be limited to specific IP addresses.

We do provide varying levels of access with MyPAYE, but this is primarily because we decided to provide the ability for individual employees to login to the payroll and print their payslips etc, or even enter their hours worked.

I understand Duane’s decision to omit multi-user access to KashFlow and time will tell if he made the correct decision, but I question the intentions of some of the bloggers having followed the various broadsides fired. Some people need to embrace the open nature of Kashflow’s approach and understand that responsible companies understand the implications of security regarding their own product and put in levels of security deemed necessary. Users don’t have to use KashGuard unless they want to.

The strange scribblings of those with allegedly no agenda or ulterior motive (sorry have to laugh) is a mindless attack that misses the point completely. Kashflow is all about simplicity and ease of use and in its pure form is aimed primarily at the single user. The fact that multi users are buying in and a development partner has set up user roles gives testimony to the growing popularity of Kashflow and the SaaS model.

We are dismayed at the total disregard of the knock on effect these kind of bloggers have bringing into question without consideration the integrity of Integration Partners like us at MyPAYE with no second thought to our business or the effect unfounded misguided and uninformed publicity can have We will be making the Kashflow link available on www.MyPAYE.co.uk/KashFlowIntegration on1st September and can assure anyone looking at MyPAYE integrated with Kashflow that our security is as good as it gets.

For the record, MyPAYE has been available for four years in its own right and has been integrated with a successful UK and USA enterprise level accounts package. You won’t read that in these bloggers postings (I think I meant bloggers).

The bottom line is Kashflow should make no apologies for providing a product in a chosen market space and MyPAYE shouldn’t be devalued by rumour and uninformed bleating from people that nothing better to do.

Security

Anonymous | | Permalink

That's a nice advert Lerryn, but perhaps in the wrong place.
But isn't the point, if you build your product on top of a weak (security) API, your product can't make that API more secure?
After all, once I simply detect the username and password being passed to the API can't I just access Kashflow's API directly, impersonate any of the users and bypass all of your product's security?

No that isn’t the point.

Anonymous | | Permalink

On what basis are you calling the Kashflow API “weak”? There’s nothing to suggest that beyond what Dennis Howlett has written. The follow-on comments show he didn’t know what he was talking about or that he deliberately set out to cause damage to Kashflow. The Kashflow blog dug up articles from other respected sources that showed he has previously written with supposed authority on subjects he knows nothing about as a personal attack on Michael Arrington.

How do you propose to “simply” detect the username and password? Communication to the Kashflow API is done using SSL encryption. The same level of encryption used by banks.

If by some miracle you do get the username and password you also need to get the user to add your IP address to the list of people allowed to access the API

And if somehow you achieved that, you wouldn’t have access to “any of the users”. Just that one individual user.

Kashflows API is no more or less secure than anything offered by any other vendors. But it does have far more extensive functionality than many of them, which I see as a good thing.

If this furore shows anything, it is that you can’t take anything written by Dennis at face value. By writing his rubbish for consumption by an audience that isn’t technical enough to comprehend why he is so wrong he has failed his readers and should be ashamed of himself.

Security is important: don't shoot the guy who raises security i

Anonymous | | Permalink

SSL traffic encyrpts traffic and proves the identity of the (Kashflow) server, that's all.
It doesn't prove the identity of the caller.
IP addresses can be spoofed.
If the caller knows, finds out, key logs, etc. the username and password; they're in. That username and password has to be stored somewhere. If apps are built upon the API, it's down to how well-written those apps are.

I'd expect greater repudiation on information so critical to my business.

My bank uses two factor authentication (a password plus a hardware generated hash). I wouldn't trust my bank if they only had username and password authentication. I'd have no way of proving that it was me that transferred my funds elsewhere.

I'm not knocking Kashflow. They've brought their product to market quickly, and I'm sure they'll strengthen their authentication very soon and this argument will be over. But I'm supporting technology professionals who raise security issues.

daveforbes's picture

Hmmm

daveforbes | | Permalink

With the exception of a small number of banks that use some sort of hardware, almost every online service comes down to username and password security.

I understand the issue raised with KashFlow was about the inability to have multiple logins with different levels of access. With our bank (which is one of the ones that uses a hardware generated one time pad) we have two authorised users that can log on, each with a userid and password. It is secure in that no one else can log in, but we cannot specify which accounts for instance the different two users can access or whether they can make payments or not.

Perhaps lacking this feature would make it unsuitable for a larger organisation, but it would be unreasonable to suggest this is some sort of massive security loophole in online banking.

Thank you

willis | | Permalink

Cool. In fact many small businesses rely solely on the accounting application. Of course there are many versions of them and each is just about the same.