Kashflow's security nightmare

by Dennis Howlett on August 13, 2009

I read a piece at CloudAve that stunned me to the point where I had to read it several times, rub my eyes, swig a cup of tea and then lie down. This is what CloudAve is saying:

The other day Duane Jackson from KashFlow pinged me and explained that user permissions is a feature that KashFlow is quite light weight – at the moment one can have multiple users logged in but their access is “all or nothing”. He explained that it’s a huge amount of work to set up and outside of their current focus (and, one assumes, sufficiently enough of an edge case as to not be seen as core functionality). He did tell me however that a third party had created an application that leveraged the openness and breadth of the KashFlow API to provide user permissions as an add-on.

For £2 per user per month businesses can sign up to KashGuard and set granular permission for different users – allowing, for example, an accounts clerk to create invoices but not create customers. The granularity of permission options is detailed in the image below;

In other words – Kashflow has no security once you get past the login front door and has exposed the ability to refine that to a third party. They’ve created a security hole that renders their existing security model useless. I’ll get to what it means in a moment.

I called up FOUR developer organizations involved with saas just to check that what I thought was correct. Two laughed out loud, one said ‘weird’ another said ‘bizarre’ and one said: ‘Wow, this is freaking insane.’

I called up Duane and asked him point blank: “Have you gone out of your f*@$ing mind? You’ve effectively handed over the keys to the kingdom to someone your users have to assume is trusted and then pay for the pleasure. That’s nuts.” Over the course of the next hour, I tried to explain the importance of this issue but Duane would only say that while he understood my point, he wasn’t seeing enough people asking for this level of security to make it commercially viable given restricted resources and that in any event, he is only appealing to mom and pop shops. The ‘not asked for it’ piece is the worst excuse anyone could mention. It’s up to developers to imagine what will be required and offer to the market but some things – like security – are not optional, they’re essential. It gets worse. Again from CloudAve:

Simon Swords, manager of Atlas Computer Systems who created KashGuard is looking at this application as the beginning of a series of add-on applications for KashFlow, ones which can leverage KashFlow’s existing customer base, offer them useful features, and dribble in some revenue in the process.

Paraphrased: Atlas owns Kashflow’s ass. And it doesn’t stop there. According to Duane, two people can edit the same record simultaneously. There is NO record locking so who knows which is the right record at any point in time?

Here are a few scenarios:

  • I am your accountant, you use Kashflow. I have full access to your stuff as I need to make adjustments. What if I want a clerk to manage the checking process? Would I necessarily want them to be able to change things? I now need KashGuard but why would I pay for it? What happens when staff leave?
  • I am a Kashflow customer. I am also a KashGuard customer. KashGuard develops something but there’s a problem. To whom do I point the finger?
  • As above but now I am also an intern. I have access to invoices. What’s to prevent me from changing bank details, issuing genuine invoices and then changing those details back the following day? Who would notice?
  • I have a sniffer application – how easy will it be for me to break the API and effectively get between Kashflow and KashGuard and so gain control of the application at the detailed level? The suggestion is that if security is already weak, then the API is unlikely to be much better.

There is a reason why CODA developed against the Force.com platform. Salesforce.com handles security as part of the infrastructure. As a developer, I must maintain my application in compliance with Salesforce.com security code and policies. When we were developing ESME last year, one of the key attractions of doing so against the SAP environment was because we could leverage the SAP NetWeaver security model. It was a highly welcomed feature and meant that we could confidently say that communications within ESME shared SAP’s security. That allows customers to seamlessly control who has access to what – vitally important in a business environment. According to David Terrar, “Twinfield has 12 levels of security and even that’s not enough for some customers.” I know of a free application that has four levels of security in case it is able to monetize. I’ve never heard of a business app developer effectively outsourcing security. It doesn’t make sense.

I pointed out to Duane that he is limiting his market because larger firms that might otherwise wish to recommend Kashflow will find that the current method of having two parties involved is unacceptable. It also means that Kashflow customers cannot reasonably extend access to customers and business partners without KashGuard because without it, anyone has access to everything. Granting customer access for say: account detail checking would be a valuable service but if I see everything once I am past the front door then who knows what might happen?

While there is nothing to stop Kashflow from building its own version of KashGuard, that will almost certainly require significant engineering effort. The best scenario would be if Kashflow acquired KashGuard and then embedded it within the existing security model, tweaking it so that Kashflow absolutely controls security. Right now however, Kashflow has a problem on its hands – a major one because KashGuard owns the detailed securuty model. CloudAve doesn’t see it that way:

As I mentioned earlier – being this tied to one particular application is a little risky but given the size of the market for SaaS accounting applications, it makes more sense for vendors like KashFlow to broaden their customer base rather than trying to cannibalize their ecosystem partners.

I think that in this one announcement, Kashflow doesn’t have to cannibalize the ecosystem. It’s just put a bullet through its brain.

  • Share/Bookmark
  • This argument seems to be very odd given how simple the situation is.

    #1 Kashflow does not have user permissions. This may be a reason for you not to buy the software - is so that's fine. Clearly lots of people don't care about this given Kashflow has customers.

    #2 Kashflow are aware that this is a feature some people might want. They may add it in the future (as they agree there are reasons for having it) but it is not a priority now. There are features their users want more.

    #3 Kashflow has a completly open API so another software company can create any sort of limiting aroud that API if they want. There seems to be a lot of misunderstanding about whan an API is and what it is for from Dennis.

    #4 Even should Kashflow add user permissions to their system which I presume they will some day, assuming they keep a full API (which they would be crazy to change) then someone could still build a permission system on top of that API if they want that replaced whatever Kashflow had created.

    #5 It seems that Dennis problem with the software has changed a lot from the FUD in the first post to it just being a matter of having to pay extra to someone else for a feature *he* belives should be included. Again, this is the exact eco-system I presume Duane is trying to create around Kashflow.

    What a storm in a teapot!

    Discloser: I am trying out Kashflow and considering being a customer - but not made my mind up yet.
  • @GretchenL - Although I've got severe misgivings about Duane's approach on this particular topic, let me add a little defence on his behalf. I'm sure things like record locking and data integrity are properly handled on the Kashflow application. The issue here is that he hasn't designed multi-level permissions in to the application at the start and says that's a bitch to do now. On the other aspects of how secure Kashflow is, I'd go check out what he says on his website.

    @Jonathan - You are highlighting my belief that most small businesses will want some extra option or granularity of access with the appropriate permissions. For me that ability to collaborate is one of the key advantages of a SaaS approach over good, but stand-alone products like MYOB. It could be the accountant, a business partner, a supplier - any size of business can benefit from that sort of collaboration. Products like e-conomic and Twinfield give the extra permission options, but Kashflow now provides this through a third party (which I still think is weird).

    @Duane - see the direct reply I've put earlier in the thread.

    @Sunir - Great comments explaining this in terms of business risk rather than the technicalities. That's the key.

    @Richard - Thanks for the name check and glad you agree. I hope Duane takes note of the amount of heat this issue has generated and reconsiders his strategy.

    I definitely don't want to get in to the middle of the @Dennis and @Ben exchange, but I do want to add a something on the integration. Provided the API provides a proper web service with the same security log in and authentication as standard Kashflow then I don't see any additional security risk from a technical point of view - it's the business risk (security in the wider sense) of introducing a third party provider for functionality that I see as core rather than add-on.
  • @David: "For me that ability to collaborate is one of the key advantages of a SaaS approach over good, but stand-alone products like MYOB. It could be the accountant, a business partner, a supplier – any size of business can benefit from that sort of collaboration."

    I agree, David.

    I would say that multi-level permissions are more valuable for a SaaS product even than for a desktop product - because of this.

    The accessibility of the data in real time to users such as an accountant is one of the big pluses of SaaS.

    So then the questions start cropping up as to which areas different users should be able to see.

    Why would a business partner / a supplier need to see the bank reconciliation, which they probably wouldn't understand if it jumped up and bit them on the nose?

    And sometimes it's useful to limit the areas an end user (business owner) can reach, such as journals.

    So I would agree that multi-level user permissions are a big plus in the SaaS world.

    If KashFlow are providing them, whether through the system itself or a third party, as an idea that's good news.

    I'm not techie enough to know whether that service is secure having read this. I don't understand a lot of the terminology. But I have a high level of respect for Dennis's expertise and an amber light from him would probably, like Richard, send me running for the hills.

    M
  • @M: for the sake of clarity and to be 100% fair on this, the industry is not good at setting standards about these issues. Therefore, vendors often have to make it up as they go along as best they can although there are emerging standards.

    However, my concern is, and always has been, that allowing a 3rd party to develop multi-level access as a very specific function, I am incurring an extra cost that should be part of the core offering from the main vendor (I don't know any other that has a separate charge for this) and in turn the main vendor is creating a problem for itself that exposes a level of risk I believe is unacceptable.

    Sunir has written a very good comment in this which I have put out as a separate post.

    Despite acknowledging the issue in our call, DJ chooses to argue about it rather than see that all but himself see this as an issue. That's a great shame because as I've said in a few places, this is easy to resolve. Buy the code.
  • Richard Murphy
    Ben

    As David Terrar says "I find it really difficult to believe that a significant subset of Duane’s small business customers aren’t asking for different levels of access for some of their directors, employees, users, or partners. "

    I know that is true

    I also know that small businesses don't want to change system too often, so best to plan for the need

    And your comment entirely ignores the reality of real world decision making. Just like buying a car there are too many decision variables for me to process when buying accounting software and too many weightings I could apply to each for any client to ever get the formula right. So whilst I can be entirely rational about buying toilet paper, I can't be when buying software, and nor are you: it is not possible to be so.

    In that case I have to allow instinct to come into play. Instinct provides me with risk warnings that say 'stay away' or even 'flee'. They're pretty valuable. Dennis has highlighted an issue where instincts say there is a problem. You can rationalise it all you like, but you'll be wasting your time. He's highlighted a danger and when that's about we rightly process it as a 'flee' reaction. Especially as in this case there are other options available elsewhere.

    Kashflow would be very wise to take note. And understand the decision making process that gives rise to it.

    As a practitioner I'd put it another way. It's a simple test, and it's "is my backside even potentially exposed by recommending this?" Answer yes, and I run a mile. Life's too short and profit too hard to come by to take that risk.

    If you haven't got the message now you never will, but any business that ignores such issues when they come up is in trouble,

    Richard
  • Richard - cheers for your reply. I'm more than happy to accept that your clients need more that what KF can offer, after all I'm in no position to question what you say - I guess the SMBs I deal with have different needs or whatever. At the end of the day that's OK, the whole "long tail" thing allows for different strokes for different folks - luckily we have Twinfield et al offering the functionality that you and your clients require. Meantime the numbers that both Xero and KashFlow are gathering is indicative that for at least a significant subset of SMBs this stuff isn't an issue.

    Agreed that there are significant variables when buying software - I guess all I'm saying is that the apps that have the functionality you need tend to be significantly more expensive than (for example) KashFlow - at some point cost comes into the decision making matrix as well.

    As a matter of interest I'd be really keen to hear what software products you do recommend to your customers.. cheers
  • I think we might all be getting away a little from the reality on the ground for small business. I'll preface this comment by saying that I own and run four small businesses and have done contract bookkeeping for half a dozen others as well as advising many more - the reality is that many of those businesses are using a traditional desktop software product that does have a bunch of permission levels - the reality is also that in my experience the vast majority of those businesses use one single login for all users.

    I'm not saying it's ideal, but I am saying that it's the fact.

    Secondly when transmitting their data to accountants they generally send a datafile and give the practitioner the admin login - therefore any conversation about needing multiple user levels for different parts of a practitioners operation are pie in the sky bunkum. It seems people are parsing this issue through an enterprise lens when in fact it's a small business issue - maybe it's a failing of the analyst community that context shift occurs so often....
  • @ben - You seem to be denying my experience but without knowledge of what professionals worry about (for good or ill.) I have the benefit of having worked for and with large,small and medium sized businesses both as an end user and as a partner in a firm as well as someone who occasionally writes code. Part of that involves regularly talking to practitioners as well as end users and vendors. It isn't as simple as you might think.

    Despite all the broo-ha-ha about CDs etc getting lost, it is an inherently 'safe' medium in that I have one account to which I can gain access so if damage arises it is relatively easy to isolate and restrict. The fact it is a PITA to manage 100's/1,000's etc of these is secondary to that and at the same time a great win for the saas players that can provide access to many accounts.

    Your point about single user/passwords etc being sprayed around is well taken - it is well known to be a material weakness in the way people operate their systems and one to which @craig alludes. But that doesn't excuse the developer from ignoring it. That's a completely separate issue.

    It may well be that today, modest forms of security are enough for many VSBs BUT - as @craig says: the 1st time there's an issue, who gets the blow back? And all that before users really start to leverage these applications out to business partners. You might say - 'OK - 5 years out, let's handle it when it's an issue' but I'm less sure. 4 yrs ago I was told: "Saas? Not in my lifetime" by many so called analysts. Today?

    But to bring this right up to date: I have professionals saying to me they won't recommend saas until they see dongles that carry encryption keys etc. of the kind that some banks operate. I think that's a tad extreme but it's not unreasonable when you consider the sensitive nature of what sits inside an accounting system.

    To your last point - I think you're missing a trick. It's got nothing to do with enterprise but about the relative maturity of the industry. Saas has plenty of battles to fight in order to get past the professionals' front door. It's one I've been battling for more than 4+ years so I think I have a good handle on the turf wars out there. It's one that all the vendors who've spoken to me raise. This is one issue where the incumbents can easily knock down this particular player and toss them out the door.

    Viewed from the other side, what happens when a tech savvy professional realizes what we're seeing here as a problem and turns to the user and says: "By the way...do you realize...?"

    As a professional, I'd like to be able to say to clients: "If you're concerned about who has access to what here then let me assure you that..." and then explain how they manage this aspect. As it stands, they can't do that in this case.

    The solution is very simple - own that aspect so that people have the peace of mind they deserve and which KF can then legitimately turn around and say: "We've got control."
  • @ben/@craig - KF has a number of add-ons that include three 3rd party payrolls.

    @ben - this would never have been an issue if it wasn't for the fact that KashGuard exists, doing what it does in the way it is able to do so. That's hardly singling out. Any other application of this kind that did the same thing would get the exact same treatment.
  • An app like KG can be written for *any* other vendor that allows the creation of invoices, customers or quotes via their API. Do you accept that?

    If so, is your argument that we shouldn't allow (in a business sense, not a technical sense) KG to exist?
  • I think I've made my position pretty clear in both the original post and subsequent comments.
  • I don't see it. Can't you clarify it? It's a pretty straightforward question, or so I thought.

    You said "this would never have been an issue if it wasn’t for the fact that KashGuard exists, doing what it does in the way it is able to do so"

    I pointed out it's possible for the equivalent of KG to be created for any other SaaS accounting vendors that allow creation and viewing of quotes/invoice/customer via an API (which I would hope is ALL of them - why else have an API?)

    So is your argument that we shouldn’t allow (in a business sense, not a technical sense) KG to exist? Perhaps by barring it in our T&Cs? I'm genuinely interested in an answer if I can get one!
  • That's not strictly true. Much would depend on what the originating vendor was prepared to allow with the API and the Ts & Cs that exist between vendors and 3rd parties. @craig seems to concur with me on the issue of who owns access control to what and where that potentially leads - I'll leave it at that.

    If nothing else, this discussion has opened the door to a much more important debate about the maturity of solutions and what the industry as a whole might wish to think about. Sunir's follow on post is a good starting point but it's not the end game.
  • It is strictly true. I covered the "what [they] are prepared to allow via the API" in my first sentence.

    The T&Cs would fall under disallowing it in a business sense rather than a technical one, as per my second sentence.

    So is that where you stand? That we shouodn't allow it from a T&C's perspective?
  • There is a use case I'd forgotten but which remains pertinent. In most practices outside the small (5 partner and less) types, there is a separation between accounts prep and tax. Very often those practices operate as though there were Chinese walls between the departments. For accounts prep, you do need read access to all for verification etc. and write access for journal corrections - assuming they're incorporated into the original books and records. For tax you only need to know about certain types of transaction but still need read access but not write access.
  • @Dennis - at the risk of you laboring a point. Yes I entirely agree on the Chinese wall separation between accounts prep and tax. But my contention is that the companies that use KashFlow and the other apps aimed at micro business don't generally have this requirement.

    So the broader issue is that your use case is not provided for by almost any of the SaaS accounting apps aimed at micro businesses - irrespective of the KF/KG issue
  • All I can tell you is that a number of the larger firms have looked at this aspect over time and raised concerns (generally) about this type of issue. I can think of two firms in particular that between them have some 30K+ clients - all VSB/SMBs. It's not just about the client.
  • I've been debating whether or not to comment here since Den posted the blog and finally decided that I wanted to at least bring up my own point of view in regards to this as a consumer as well as a developer.

    First though I'll put in the typical disclaimers, I know Dennis and have now for a few years. I'm an Enterprise Irregular as well as an Enterprise Geek, I work for a large Enterprise company that provides financial software and solutions. I've been developing applications for small (mom and pop) to large Enterprise customers most of my life (yes the true geek who started programming at the age of 8) - I also have no stack in this topic what so ever, I'm not into finance and I'm not a provider of SaaS solutions but I am somewhat who is very interested in technology and when I see something that truly baffles me I give it some thought.

    I also know Ben although only through others and from online and I read Cloud Ave as well as ZDNet.

    My comments here are my own as someone who used to do massive system integrations I'm also someone who was often called upon to think "what could go wrong"; often these "what if" conversations where always the most interesting part of system design.

    I don't know KashFlow nor KashGuard beyond what I've read here and on their sites but a few things spring to my mind.

    1) The Open API is ideal for folks like me so kudos to KF for doing that and getting that part right
    2) As a developer I can only sympathize with the KF developers who probably beat their heads against a wall trying to convince Duane that a bit more security is required to no avail as Duane has said it was a business decision based on their target audience - can't fault the guy for making hard decisions
    3) I think that decision will come back to haunt him here in the near future
    4) KG major kudos for that little win, providing what most consider a standard feature using an open API - who has to wonder though the 5 year plan? Slowly expand the offering until you have a nice "migrate your data to our 'complete' solution" (Sunir mentions that as well) so yes I can see where Dennis says KG owns KF now...
    5) the lack of data privacy is simply scary

    And with that item number 5 I'd like to expand what I mean since it may not be overly obvious. Some of my first jobs were in the so called "mom and pop" shops in the US and I can't recall a single one I worked for or did work for that had the same access for everyone there was always a separation of customer data and order data so when interns or high school kids were entering in accounts payable or receivable they worked simply with a customer number and not all the customer data. Again not a financial person here but that makes sense to me, especially when I give a testimonial to the company whose service I decide to use. Some nice testimonials and of course not all are the local corner store some seem a bit high profile and a malicious person could of course target that list and then target those customers - get in the door on the low end and still get full access to the system including customer details - sounds kind of like a movie but I don't think it's implausible do you?

    For me I see security holes but that's because there are always holes in security but I see a major security risk where KF unintentionally has left it's customers vulnerable - part of SaaS is about trust that your data is secure but also trust that the tools and services you are using are doing the due diligence to ensure that they (the users) can't hurt themselves because they assume one thing or another? Isn't educating the user on risk part and parcel for the package?

    Despite all that I do hope KF succeeds but I can only recommend they take a closer look at this because I don't believe a single business is going to simply hand over it's entire book keeping (the paper ones) to everyone in the business and accountants - sheesh (no offense Den) but can you really trust someone who is not "inside your shop" who probably saves their password in the browser and does nothing to encrypt their computer (how many of you do that?)

    I see a high risk associated but again I do look at things from a more enterprise level so many those 1000 or so customers are perfectly happy not knowing the risk they might have opened themselves up to - ignorance is bliss right? On the side I also understand that KF says it rests with them and on he other side I personally want a service that will help me minimize my risk especially when it comes to my money...
  • Craig - Awesome comment, well done. You obviously know this stuff better than me but the only thing I'd say is that the vast majority of SMB SaaS accounting applications only have very limited permission levels so your concerns (that an intern at a practice may have full read/write access to a clients data) is in fact borne out in the majority of cases.

    You're correct in asserting that this is any area of concern (although I'd argue less so for SMBs than larger organizations) - but my point is merely to say that Dennis is wrong to single KashFlow out for criticism around this (and yes, my previous disclaimers still hold)
  • Not so sure on that Ben, are you saying the majority have a single user access level? My experience (very limited in these types of applications is typically a 5 level access)

    - Super Admin (access to everything and all accounts) as well as adding new accounts
    - Admin - ability to add new users to individual accounts
    - 3 levels of access from Read/Write to just read

    as for Dennis having "singled out" KF I certainly hope there are not more SaaS solutions that provide a single access level application unless they are targeting a single individual such as the majority of social networks (remember most of those have at least 2 if not 3 levels) - for example Twitter has 2 levels, flickr has 3 levels and I'd like to think the folks wanting to take care of my money have given it a bit more thought. If there are more I fully hope someone brings the topic up!

    Imagine working for a company using a "single level access" like this but they also maintain payroll in it (I did not see that KF does payroll or do they?) - everyone would have full access to your personal data and pay rate. One person decides they don't like you and quicker than you can think (without audit trail) they can steal your identity and cause some havoc, simply because they needed the ability to invoice a customer?

    Again though Duane stated it was not a priority for their target audience; I'm wiling o bet the first one that gets compromised will either leave or "demand" KF to "fix the problem" but then again perhaps I am simply to risk averse based on our own research into the SMB space (but I think we differ on the sizes of what the SMB space covers - topic for another post I guess).

    I still hope they do well and have no major issues but personally that's one solution I'll not be using...
  • Hey Craig - the majority of SaaS apps don't have the granular control that would solve the use cases that Dennis originally brought up.

    Re payroll, no KF does not have payroll and yes, most payroll applications that I've used have at least 2 levels of security (and most have three - employee view, foreman view and admin view)
  • @dennis If you have info from Parker Harris and Marc Benioff that Salesforce is going to support greater collaboration both in terms of the features they offer and their licensing/pricing model then that can only be great news. But I hardly think it is "being hasty" to state the position as it stands which is that the lack of support for collaboration that you highlight as being one of the issues with the Kashflow security model is also an issue in SFdC for entirely different reasons.

    However, as you say, this is a thread about Kashflow and the security risks you perceive. My view: of your seven 'use cases' only one is *really* about security. Kashflow's model is clear: if you use their service you either shouldn't allow access to externals or you have to put in place the same checks and balances that you would with a more traditional system. I've run two small businesses in the last 12 years, each with a turnover of £0.5-1m p.a and I've never felt the need for that level of security nor fallen foul of the revenue, the bank, the accountant or my customers and suppliers. Obviously this will not be true for many other businesses and I would imagine they either would never buy KF or will migrate to a product with a more sophisticated security model when they need to. Is this a missed opportunity for KF? Only time will tell.

    KashGuard complicates the issue or increases choice depending on your point of view. The value-add model of software supply has been around as long as commercial software and at least two of your 'use cases' merely describe the situation any vendor finds themselves in when they support 3rd parties in enhancing their core product with additional software or services (and even in some cases where they actively discourage 3rd parties from doing so).

    The real security risk you raise, that Saas-based software is inherently more vulnerable to sniffers and API exploits than behind-the-firewall on-premise solutions, is a universal problem, not a KF-specific one (and I have to say that I'm one of those who believes that, in real terms, Saas offers greater security than most on-premise solutions). As working in the cloud becomes the norm this issue of openness of API's vs. security of identity and data is going to be revisited many times over because it is vital that Saas solutions can work together for the benefit of the customer. So we need to have a sensible discussion about what security models work and what responsibilities vendors (and users) have; as @sunir has started to do here.
  • @paul -Mostly I'm not arguing against what you say...without breaking the NDA I can say that your suppositions are 'top of mind' - we have to wait and see if that gets articulated in the real world and critique accordingly.

    Saas/on-demand faces the big issue of: 'Do you offer world class security' - the answer to which is usually something like: 'We offer bank grade security by...' First line of defense and usually all good - inc KF explanation. Except...they've acknowledged it's all or nothing and 3rd parties can control - via permissions with KashGuard - important pieces of the app. That remains a big deal that the peeps I spoke with could not fathom and saw askance. Once they understood what was being said they were even more concerned because KF is playing a different sec model + tby their own words...Atlas intends creating apps that leverage THEIR sec model. ergo KF loses control of the app at every level. As I said from day one - that's nuts given the value saas should deliver.

    in the meantime I've spoken with Freshbooks who provided an opinion I've surfaced as a fresh post. As the only near complete view it was worth setting apart IMO.
  • Dennis - you criticised me off-record for having provided no cogent response to your so called use cases so here goes.....

    1)I am your accountant, you use Kashflow. I have full access to your stuff as I need to make adjustments. What if I want a clerk to manage the checking process? Would I necessarily want them to be able to change things? I now need KashGuard but why would I pay for it? What happens when staff leave?

    Have you actually looked at homw many SaaS apps provide this granular level of permissioning. I have and the answer is very very few. As such KashGuard gives users an option they don't have with many other SaaS apps aimed at the micro end of the market

    2) I am a Kashflow customer. I am also a KashGuard customer. KashGuard develops something but there’s a problem. To whom do I point the finger?

    To both vendors. KF is promoting the app so holds some liability if things go wrong. As your paying for a service from KG you also have cause for action at that end. How is this any different from the million and one twitter apps we all use pray tell?

    3) As above but now I am also an intern. I have access to invoices. What’s to prevent me from changing bank details, issuing genuine invoices and then changing those details back the following day? Who would notice?

    This is bunkum - as in 1 - most SaaS apps only have very limited permission levels - as such your "use case" would hold for any application. You're articulating an argument that the SaaS naysayers trot out with great regularity

    4) I have a sniffer application – how easy will it be for me to break the API and effectively get between Kashflow and KashGuard and so gain control of the application at the detailed level? The suggestion is that if security is already weak, then the API is unlikely to be much better.

    I'm no security expert and Sunir has pointed out some issues with the KF security model - however multiple password levels a code word requests (remember that I've actually used KashFlow so do have some idea of what I'm writing about) give some protection from sniffer apps. Agreed OAuth would be better and hoping Duane will work on that ASAP

    5) what happens if Atlas goes out of business with paying customers on board?

    Those customers lose granular control over permissions - beyond that very little - the data is still held by KF

    6) what happens if Atlas is sold?

    as above

    7) how would Kashflow manage to convince a potential buyer of the business that it has developed business grtade security?

    Well - agreed there are a few failings with the KF model but I don't believe this particular issue calls into question their security per se

    Anyway - I think it best to disclose here, just in case anyway incorrectly thought that there was any business relationship between Duane and myself, there is not. I am an independant commentator - my disclosure page lists all my past and present commercial relationships and KashFlow (and for that matter no UK SaaS accounting vendor) does not appear there.
  • @Ben - I won't go into detail because it is obvious you have no clue what you're talking about. Instead of answering the questions intelligently you try trash them or gloss over - as a self proclaimed 'evangelist' that's idiotic and a clear expression of your (non) appreciation of the issues. I note you now admit you're not a security expert so my question to you is this: why opine on a topic that by your own admission you know nothing about? I leave it to others to draw conclusions. I don't claim there is a biz relationship between you and KF but I do say there is an uncritical acceptance of this story you've been sold. Bottom line - you don't know what the heck you're talking about but pretend otherwise.
  • Dennis - I believe the reality as articulated by both Sunir and Duane would suggest that my thoughts around KashGuard are in fact closer to the actuality than yours - simply throwing accusations of my idiocy or otherwise doesn't change that fact. I answered your multiple "use cases" as you requested I should - if these answers conflict with your view of the world that's unfortunate but it's just the way it is.

    As I've mentioned previously, no I'm not a security expert but I am a small business expert having actually owned and run multiple small businesses over the past couple of decades or so, this experience, along with the experience gained from having used almost every SaaS accounting application led to my post, not any "uncritical acceptance" as you surmise.
  • @ben - that's possibly the most asinine answer I've seen to any question I've raised. What's wrong with admitting that you don't know what you're talking about, didn't review what this means and didn't check the veracity of what Duane was saying. That's what I did...in other words admit that you shill whatever KF tell you without thinking. Believe me when I say the interwebs will forgive you - otherwise they won't
  • Jim Bennett
    Have to say, I think ben/duane are coming across more convincingly. Default KashFlow sans KG gives secure access for one user at a time. Don't think that is disputed. Dennis thinks there should be multiple user security levels for KF to be viable. Duane and the majority of his customers disagree, or don't see it as a major priority.

    Perhaps I'm missing something, but if the customer is happy with the security offered, or chooses to take on KG for extra options, where exactly is the problem? Maybe Duane would have done things differently if he were to do it again, but that's a theoretical exercise that, while fun, probably doesn't add much value.
  • This post is pretty confounding. For those too bored to read this epic comment (I get paid by the word, right?), I am the head of integrations at FreshBooks, and I am intimately aware of these issues as I face them every day.


    JUST THE FACTS

    KashGuard is an application that operations KashFlow like a marionette. KashGuard essentially "drives" KashFlow through its own user interface, which interacts with KashFlow through the API. By bolting on a separate UI, KashGuard allows its end users to add fine grained user-permissioning. Atlas built KashGuard because there was a perceived market opportunity to sell to customers who needed far greater control over data visibility than **security already built into KashFlow**.

    There are two prongs of reaction to this. The first is does this by itself create a security issue. The second is was this wise for KashFlow to do?


    SECURITY

    First, one of the key principles of good SaaS is that users own their own data, and they should have the right to migrate and manipulate that data using any other software *they* choose. It should not be KashFlow's right to *impede* that flow. As KashFlow rightly has an open API, then it's perfectly reasonable for KashGuard to exist.

    Now, is there a security threat? There is the same question to the end user when using KashGuard as when using KashFlow: Can I trust this company with my data? That is the end user's chosen risk. Does this create any further information theoretic risk to the end user? Yes, but not beyond the idea of spreading end user data to more services, which is the same problem experienced by ANY integration. It's immaterial this application provides user permissioning.

    It's important to separate the idea of open APIs from the premise of this particular integration. I think the freedom of open APIs trumps any risk of exercising that freedom.


    BUSINESS RISK

    So, yes, there is more risk in letting more third parties gain access to your data. More servers, more people, more transactions. Every SaaS company hears this question routinely. However, if KashFlow fails to protect the sanctity of user data, that news would get around, and they would be out of business. Similarly for KashGuard. So on the face of it, that's all fine.

    The question of whom to hold accountable if something goes wrong is actually simple. Since KashFlow promoted KashGuard, you hold both KashGuard and KashFlow to account.


    THE REAL BUSINESS

    But that's ignoring the particular nature of this integration. There are several bad things about it. First, allowing a third party to extend your brand is bad (we've struggled with that at FreshBooks). It implies to the end user a special responsibility for this integration. Second, as the proxy billing agent for the integration, KashFlow is taking an even more proactive role. Third, by encouraging third parties to totally reskin the KashFlow experience, it opens up the opportunity for third parties to learn and replace you.

    I think this really hurts their brand.

    That being said, I don't feel there is anything wrong about creating an app that publishes limited data from the KashFlow account to specific end users. I think that's pretty valuable. Though I think the name of the integration is incredibly stupid. Focusing on security rather than the real value--workflow--is what caused this flap in the first place. It immediately creates the question, "Is this secure?" And everyone's first reaction is no.


    MORE ON SECURITY

    I will say that KashFlow's API is not using the best authentication method. Most SaaS companies choose one of two approaches to authenticating with an API. 1. Use the same username and password in the API, which means giving a third party your username and password; or 2. use a random string as an authentication token, which at least does not encourage sharing a user's password with third parties.

    The one KashFlow chose is to use the same username and password as used by their normal web login. I will say that at least KashFlow does use a second level of authentication in the web app to thwart keyloggers. This also makes it insufficient to merely compromise a third-party integration in order to break into any KashFlow account. To understand this threat, recently there was at least one Twitter integration that collected usernames and passwords which ended up using those usernames and passwords to spam from victim accounts.

    FreshBooks uses option 2, and it is still not ideal. While the random string will not allow a third party to compromise your actual account, there is no way to block one specific compromised integration. It's an all or nothing deal.

    The correct solution is to implement http://www.oauth.net which leaks no end user authentication information to third parties, and it gives both the end user and the vendor the ability to terminate access with compromised integrations. FreshBooks is heavily investing in building a secure OAuth endpoint. I encourage anyone who got all the way down here to push heavily for OAuth.

    Cheers,
    Sunir Shah,
    Chief Handshaker, FreshBooks
    http://twitter.com/sunir
  • Hi Sunir,

    Wading through the mess of this comment section, I'm delighted to come across your insightful post, which clarifies very well that the KashGuard/KashFlow integration, despite being *about* permissions, does not impede KashFlow's security on a technical level more than *any other* API usage impedes the security of the accessed application.

    Cheers,

    Thorsten
  • @Sunir - as always you've done well. Despite once having called me a poopy head, you've always shown yourself to rise up above the rhetoric and inflammatory comments to actually look at the real issues around an... issue.

    I'm glad to see you concur with much of my perspective namely;

    - It's unfortunate that KF didn't do this themselves to start off with
    - there is nothing inherently wrong with what KG are doing
    - there are some business risks around this but it is, as always a risk vs return equation

    It's always risky to blindly believe the comments of those with vested interests. In all of this you guys, being a player on the other side of the Atlantic primarily are probably most neutral....

    This thing is a mountain out of a molehill and, while it may be good for blog traffic, it does nothing good for the credibility of SaaS overall.
  • @ben - that's self congratultory BS that fails to deal with the substantive issues I raised. And please don't say this is a mountain out of a molehill - the use case scenarios are still there and which have yet to be answered by anyone promoting this 'stuff.'

    Having said that @sunir has written an excellent answer that will be surfaced as a guest post.
  • I believe I've now answered your "use cases"

    I'm also not sure how you, on the one hand, congratulate @Sunir on his reply and call mine BS when, on many of the substantive issues, Sunir's perspective both agrees with mine and disagrees with yours
  • Hi Sunir,

    Thanks for bringing the voice of reason to the party.

    Just to clarify though - we DON'T act as proxy billing agent for the KashGuard application, nor would we. They deal with that themselves.

    You make valid points regrding AI authorisation. As an added measure, users also have to authorise remote applications by entering their IP address,

    I agree that oAuth is what we should be using, and it's actually something we're currently working on.

    Your comments re the brand aspect of it all are also good food for thought.

    Thanks again.
  • @Chris Tanner "If you ain’t built it from the ground up to deal with multi users, it’s a complete re write to do it properly"

    Nail firmly hit on the head! We never factored in multi-level permissions on day one, so to retro-fit it now - whilst not a complete rewrite - would be a b!tch of a job.

    Glad my loss if your gain though! : )
  • Nesjo
    Nice to see a journalist looking beyond the reportage and delivering real quality. Thanks for the steer. Sounds like a nightmare bungle from the vendor.
  • @Gretchen - sorry but you're utterly misunderstanding this issue since your experience is in enterprise software. Of course KashFlow is not selling a product that "comes out of the box with no security whatsoever". That's just ridiculous. KF has the same security as other SMB vendors - what KF doesn't have is multi level security settings and this is what KG provides for.

    @Jonathan - one of the core features of SaaS accounting IS that you can allow your accountant to access and amend your data in real time. There's many accountants that would say allowing business people to use software is risky as they screw it up. I guess if your perspective is that allowing people to collaborate is to risky because of perceived problems.... then you're just not ready for the SaaS world.

    @all - personally I also find it strange that customers aren't asking for this sort of functionality. Having said that, I use Xero another SaaS accounting application and it has only a couple of different security profiles so maybe the SMB market isn't that concerned about this stuff. In terms of suggesting that KF is "outsourcing" it's entire security layer, I believe this is incorrect. My understanding is that a KF customer must authorise KG to access their account, and from there different profiles can be set up. This authorisation can be revoked at any time and the user still has control over the profiles - I think some people are getting a little confused over this.

    All APIs allow access to the receiving application - this is the whole idea of an API, so in theory any API partner could "screw up" transactions - the ecosystem is protected however through both self regulation AND the fact that the application owner has to authorise and API integration....

    Mountains out of molehills?
  • At the risk of sounding rude Ben - your security experience is what? @gretchen comes at this with not only 10 years in the game but experience with books and records. At least give her credit for reinforcing the use case issues I shared in this post. Less shilling and more analysis would go a long way towards recognizing that in allowing a 3rd party to do what it has, KF opened the door to this discussion.

    One of the core features of saas ISN'T that you allow your accountant access but with appropriate permissions they MAY have access. This was something that accountants were asking about last year.

    To amplify that by saying: "I guess if your perspective is that allowing people to collaborate is to risky because of perceived problems…. then you’re just not ready for the SaaS world." is not only naive but dangerous. It is exactly the kind of answer with which the naysayers will slam you over the head, interpreting that as 'security doesn't matter.'
  • "One of the core features of saas ISN’T that you allow your accountant access but with appropriate permissions they MAY have access. This was something that accountants were asking about last year." - sure - and KF, through KG allows for this. @Jonathan was concerned around giving accountants read/write access to a user's account.... if this is a point of concern when, to be honest it's a core value proposition of SaaS, then I'm not sure how to take the conversation forwards.

    SaaS is (at least in part) about collaboration (albeit well structured collaboration). Having an accountant work on your live data is collaboration. But if that is perceived as a bad thing....
  • Last week we turned the tables and gave the user the access to change the permissions of their advisor, who had previously been given invisible super powers as an "authorised" user. Turns out that accountants often aren't very good at judging the needs of the business best. If you ain't built it from the ground up to deal with multi users, it's a complete re write to do it properly, so I suspect KF will be in the single user market for a while. We're starting to see users come out of the top of KF when they hit ceilings. Go Kashflow!
  • I know this is a bit of a geek security thread but I was interested in this as I am testing kashflow, and the main problem as I can see it is if you offer site of your books to another ...your accountant, s/he or an employee could alter things and screw it up.
    My alternative is e-conomic another online product, whose GUI is so awful to turn me off wanting to use it at all.
    I am now a small business man wanting a simple usable answer to my business problems, if i don't use kashflow, i use a product like MYOB or another simple small business package....I have used Access Accounts in companies where i have worked and its more for the larger enterprise.
    MYOB account edge is restricted to one machine, how does my business partner get to look at the accounts when she is mostly doing outreach?
    We arw a small outfit and for us kashflow seems ideal, up until the point where the accountant looks at it.
    I don't take all your comment, but there should be a "view only" access or similar available
  • Hi Jonathan,

    You might consider having a look at re-cursion any-ware, and specifically the entry level version at www.CompleteBizOnline.com which addresses much the same market as is being discussed here. As a company, we at re-cursion are primarily interested in giving you that "usable answer to your business problems", even if we have an opinion on the rest of this discussion.

    In short, we have a fine grained user/group security model, and a LOT of other functionality, as well as accounts. Feel free to get in touch, if you'd like more info. We really enjoy talking to customers and prospective customers.
  • GretchenL
    Dennis,
    I had to read your blog post three times, because the first two times, I was sure I had misunderstood. Surely a software provider was not in good conscience selling a saas product that came out of the box with no security whatsoever and expecting the needs of even the smallest business concern to be satisfied. As you've noted, turning over the security "option" to yet another party further compounds the risk. To me this sounds like many of the worst fears about saas realized in one convenient stop. Before my 10+ years in SAP security, I spent some time as a bookkeeper/ general accounting clerk for both a small professional corporation and for a limited partnership. Bookkeeping is hardly rocket science, but if the operation warrants something more than a simple off the shelf bookkeeping program, code that enables locking the data records to ensure data integrity ought to be considered a bare minimum, as well as the ability to segregate duties even at a very high level. As this software service is described, i would consider myself better off keeping books manually. If these customers do not know enough to ask for more, the first time their banker or tax preparer asks to see their books, I would expect that they soon will.
  • It seems you've been taking in by Dennis's hype.

    KashFlow isn't a "product... with no security whatsoever". That's a ridiculous statement to make. We'd have hardly had the modest success we've had to date if that was the case.

    Nor have we turned over anything to anyone - third parties are welcome to develop whatever they like against our API.

    "If these customers do not know enough to ask for more, the first time their banker or tax preparer asks to see their books, I would expect that they soon will"

    Then you expect wrongly. Dig a little deeper.
  • Hype? What hype? Ben's the man for that not me dude ;)
  • What security model does a small business owner who keeps his "books" in, well, books (i.e. on paper) have? The answer is that he has "real world" ways of keeping an eye on what his staff are up to, that's if he has any staff. So, moving him up the food chain to a computerised accounting system, SAAS or old school makes no difference - he will still make sure that people aren't fiddling their expenses.

    Now, fast forward 5 years and suddenly our guy operates from three locations and has 50 staff. His accounting transactions have increased 100-fold in volume. Maybe now he would appreciate it if his accounting system could help out with the security side of things. Although, even then, the same "real world" checks are probably in place and needed.

    I think this is the crux of the debate here and it's just the familiar "horses for courses" rule. CODA and Twinfield are very powerful and secure systems, Xero and Kashflow are very easy to use systems. At different stages in the life of a business they each have a part to play. I have experience of the Twinfield user roles and security model and I never understood it, there was a matrix on an XL spreadsheet that was like looking at a Sudoku puzzle as far as I was concerned.

    Most small businesses and their owners will only ever need Xero or Kashflow, so please, please, please let's not drive them crazy with military-strenght security. If someone has changed bank details on sales invoices, the owner will find out, trust me.
  • @Adrian The "complicated" spreadsheet you refer to is a table/list of what functionality is available to each of the 9 levels of users - the idea being that you only pay for the functionality a particular user actually needs. I'm surprized an accountant has a problem with a simple Excel document like that... but the most important thing you say is horses for courses.... More comprehensive systems like CODA and Twinfield always have to strike a balance between usability and confusing people with the additional options that have avalable. Ease of use is really important, and we software providers need to keep working at it until we get to the stage where everything is as intuitive as using the shopping cart on Amazon.
  • @David, of course, as an accountant I am very comfortable working with Excel spreadheets but spreadsheets are for manipulating numbers. The Twinfield Excel matrix was always difficult to interpret for me, that's a fact. I wish Xero had more detailed user roles but in the meantime I will happily settle for the trade off between ease of use and functionality. When a business grows to need Twinfield, that business can invest the time to understand and configure the user roles. In my view Xero and Twinfield are not competitive products, they exist in the same space for different types of customer. And for the record, I think Twinfield is a great product - when it's the right horse for a particular business's course.
  • @Adrian - Understand where you are coming from - if the user finds something confusing, we've got to fix/improve it. Many thanks for the kind words on Twinfield - much appreciated.
  • I think I was probably the one that said "weird" when Dennis rang me to ask my opinion. I find it really difficult to believe that a significant subset of Duane's small business customers aren't asking for different levels of access for some of their directors, employes, users, or partners. Even if the demand really isn't there, I would have thought it would be sending the wrong signal to the customer base to hand over such a vital area as security profiles to a third party provider. In any case from a design point of view I'm surprised you can do this through the API, if it isn't in the core product already.

    If I was in Duane's position and I couldn't afford to develop this myself, I would have tried to do some form of deal which kept it as my own branded Kashflow module, and pay the third party royalties.

    The other points made by Duane and Ben around building a healthy developer ecosystem are all valid, and I hope they succeed with it. I just feel that it's difficult enough to sell good software (SaaS or any kind) without adding a step to explan why such a core thing as security and permissions are from a third party.
  • @Duane - You and @Ben seem to be listening to Richard, but only selectively. I agree that you only have to check out the KashGaurd guys if you need their app too. It's my contention that, because "kollaboration" is king in SaaS, a significant subset (IMHO probably most) will want that functionality, and Richard agrees with me. That's not just about a security perception, it's the opinion of the kind of thought leader in your sector that you need as a supporter. This topic has obviously stuck a nerve, otherwise there wouldn't be 79 responses and counting. If I were you I'd take serious note, start discussing it actively with your customer set, and shift it to a much higher priority in your product roadmap.
  • Hi David,

    I can perfectly understand your reaction of "weird" as a response to seeing we're not currently planing on adding granular permissions ourselves.

    But do you agree with Dennis premise that this approach creates a "securtity hole" or that it leads to anyone owning our arse?
  • @Duane - I wouldn't describe it as a security hole, but I do see it as a business risk. I also wouldn't use the same colourful language as Dennis, but his description is just another way of verbalizing the risk. You've still got the one master key that unlocks the main gate, but you've handed over the keys to all of the internal rooms to a third party. Whether it's Group 4 or whoever, I've now got to check those guys out as well as you when I'm considering your system. I think that's a strategic mistake, corroborated by somebody as respected as Richard Murphy saying he won't recommend you on the strength of this issue.
  • But no keys have been handed over to anyone. As I pointed out to Dennis (and it seems to have stumped him as he hasn't been able to reply) - an app like KashGuard can be written for any vendor that allows the creation/viewing of invoices/quotes/customers via it's API.

    You don't need to check those guys out when considering our system. You have to check those guys out if you're using THEIR system as well as ours.

    If you don't give them your API credentials then they have no access to your account.

    But as Richard rightly says, it's all about perception. And the way Dennis has framed this leads to an incorrect perception. Whether he's done that deliberately our out of ignorance, I'm not sure.
  • To say that "some things – like security – are not optional" is a vast over-simplification. Security is not a black-and-white issue and you don't either have it or not; there are many different levels and types of security. And there is definitely no such thing as "business grade security", only an appropriate level of security for your business and your users.

    Security in particular has a cost to the user as well as the provider. The salesforce security model is relatively simple but it still requires an admin to set up groups and profiles and configure permissions appropriately (as well as to deal with confused users who can't access the bits of the system they expected to be able to access). If you're a very small business or a single accountant - which is what I understand the majority of Kashflow's customers to be - this is an unnecessary overhead. If you're a 30-person business with an accounts team - which is what I understand the majority of CODA2go's customers to be - then there is no question you need a salesforce-style security model.

    The question of whether the Kashflow security model is appropriate for their business and users will be borne out by the success (or failure) of the business.
  • @paul - I agree that context matters and as Duane points out, his customers are mom and pop shops. However, that's not really my point. It's the 3rd party element plus the stated intention of adding in functionality based on a secondary security model not controlled by KF that creates a risk.

    Taking your point one step further, you could argue that with a £10 app you get £10 worth of security but to me that's also an over simplification.

    Regardless, one of the key long term benefits of saas is the ability to draw in business partners in real time, the most obvious and immediate being your professional advisors. In this scenario, they've effectively snuffed out that option. You can argue appropriateness again but that would be to deny a differentiator that delivers strong value.
  • "[KashFlows/Duanes] stated intention of adding in functionality based on a secondary security model not controlled by KF

    Maybe that's where the root of your confusion lies. Where/when have I stated we're adding functionality based on a secondary security model we don't control?
  • I ain't confused Duane and I didn't say KF in that context
  • If Kashflow are saying they will build features based on the KashGuard model then that's clearly brain-damaged but I didn't get that from your post or Duanne's reply and I'd be very surprised if he was considering that; I think Kashflow has a clear and sensible approach to their provision of an API.

    I agree with your vision of saas as providing a more collaborative environment for people to work in but this isn't all about security either. Salesforce don't support external collaboration because they have a per-user licensing model and, other than the partner portal (which only provides collaboration in the same way as, say, email) and the extremely limited salesforce2salesforce there is no way to invite your partners to work with you on your data other than buying a license for them. I bet you have more chance of convincing Duanne Jackson to implement your security model than you do of convincing Marc Benioff of abandoning his licensing model.

    I can't understand your point about a £10 app having £10 of security. I've made my living building e-commerce systems for large corporates with multi-million pound budgets and even there we have intense debates about how much of the budget can be spent on security. Fundamentally *every* decision about feature delivery, whether that's an end-user feature, usability, security, performance, manageability or whatever comes down to a value judgement. And Kashflow clearly don't see the value in your security model ... which may be a very bad call or a very good one. I have to say, given the strength of Duanne's business growth vs. the weakness (IMO) of your argument, I'm inclined to go with him on this one.
  • At the risk of repeating myself, KF has introduced an element that implies risk. I've spelled out 7 potential scenarios where - in their model - a risk could and may well arise. It took me all of 5 minutes to identify those. I don't see anyone disputing them. The degree of risk MAY be small given the universe of KF customers today but could easily be amplified. And it only needs one major cock up for that to mean game over.

    @duane was the person who said that he has constrained resources. That's a function of revenue. err - as to model - it's not mine but his. In allowing a 3rd party to do as they have, KF opened the door to this topic.

    re: SFdC - you're misinterpreting what I've said. I wasn't drawing a comparison but pointing out the obvious on model ownership as I did re: SAP etc. Yes - they're a different class of app etc but the point remains the same: no-one I know effectively outsources a good chunk of their security to a 3rd party.

    But if you want to draw SFdC into the conversation I'd suggest you're being a tad hasty. I recently met with co-founder Parker Harris (who also owns the tech issues for SFdC) and it was a significant NDA discussion topic.

    As for Benioff? Some of us have seats at the Big Man's Table. He listens. But then this isn't about MB/SFdC's business model (which IS negotiable)...that might be for another day. ;)
  • From what I know about the demographic of Kashflow users, that level of granularity is overkill, security measures aside.
  • Richard Murphy
    Duane

    Let's put it this way: there's not a hope in hell I'd recommend a product with these weaknesses in it to client

    Perception is king

    Dennis has pointed out a potential flaw

    It's big enough to make me say 'no way'

    You have a problem

    Richard Murphy FCA
  • So Richard you're saying that you'll not recommend any product that doesn't have granular user perimissioning as a standard feature?

    There goes the chance of offering your micro clients the benefits that SaaS could bring...

    Perception may be King but it's also risky to make a judgement based on it, doesn't the profession owe it to its clients to perform a prudent due diligence process before making knee-jerk reactions?
  • @duane: I don't say these things lightly and as I said in the piece, I spoke with 4 devs to sanity check. I asked them to read the original CloudAve piece first. Not one of them could find anything positive to say about this. Repsonse ranged from puzzlement through to incredulity and shock.

    Of course Atlas doesn't have special access because you haven't built the controls into the system in the first place. That's the whole point.

    Whether Atlas is at risk or not isn't an argument in this context - it's stating the obvious.

    @ben: with respect - you're not a code jock or security expert. Check the use cases and think it through. I'll give you 3 more:
    1. what happens if Atlas goes out of business with paying customers on board?
    2. what happens if Atlas is sold?
    3. how would Kashflow manage to convince a potential buyer of the business that it has developed business grtade security?

    Any of those 3 cases alone represent a risk some might not be prepared to take.

    I stand by my position as verified by others. This is not trivial.
  • Following on, I notice that at CPA Trendlines, questions are being asked about confidentiality and the potential for liability issues. That's yet another possible problem.

    See: http://cpatrendlines.com/2009/08/10/survey-results-is-cpa-tech-spending-set-to-surge/
  • Dennis - my understanding is that a user gives KashGuard their authentication and then KashGuard gives granular control up to the initial authentication. As such it is no different from a customer giving a third party app authentication for an API and then that third party screwing something up.

    It's valid to question why KashFlow aren't doing this themselves but in terms of security you've got the wrong end of the stick I'm afraid
  • Your answers to the qu's raised show your lack of comprehension of what matters in the market. And please - since by your own confession you know nothing about security then by definition you are unqualified to speak on that subject.
  • Dennis - just for the record Xero - a vendor that we're both positive about and one that is proving very succesful in the market which you have a great understanding of, has similarly low levels of granular access control to that which KashFlow has - many of your use cases (specifically 1,2 and 3) apply to them also
  • They’ve created a security hole that renders their existing security model useless
    You’re missing the point. We’ve not “created” anything. Certainly not a “security hole”. I guess you’re not as technically minded as I thought you may have been. Our security is as good as it was before the guys at Atlas developed KashGuard.
    Anyone can create whatever they like using our API. Whether a KashFlow customer uses or sees value in what a third-party has developed or not is up to them. At least they have the choice.

    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.

    We’ve no plans to add sub-accounts with definable permissions within KashFlow in the immediate future. The low level of demand for it means it’s not currently scheduled for development. I know you see sub-accounts with definable permissions as being a fundamental requirement rather than optional feature, but I don’t and nor do the majority of our thousands of customers.

    Atlas however needed the permissions themselves and decided, rather than just creating a private bespoke app for themselves to use, they would instead make it publicly available for anyone else that needed it. Good on them, I hope they do well.

    But to say Atlas “own our arse” is ridiculous. Ben at CloudAve has it right in saying that it’s actually Atlas that are in a precarious position should we decide to develop the function with the app at some point.

    There’s actually another company I am aware of about to launch something similar to KashGuard – another permissions plug-in for KashFlow. Will they have a timeshare on our arse?

    What about all of the other apps that integrate into KashFlow? Do they somehow own us too? I don’t follow the logic on this one I’m afraid.

    I pointed out to Duane that he is limiting his market
    And on that point you’re 100% correct.

    We are limiting our market by not immediately developing sub-accounts with definable permissions. 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.

    It may well be the wrong decision, the market will decide. But either way, it doesn’t create any security problems for anyone.
blog comments powered by Disqus

Previous post:

Next post: