The State of Password Security

I’ve written in the past about security in the cloud and the fact that moving to the cloud doesn’t remove all obligations from users to ensure their data is safe. While undeniably using cloud services means that users can forget about many factors (the security of the siting of your server for example), there are still lots of things that users need to think about. Primary among these factors are passwords – the rise of cloud and SaaS has led to a huge increase in the number of individual passwords that users have – it’s no surprise then that this is one area that users tend to be a little sloppy in their attention and accordingly is often the first point of call that can be exploited by attackers

Recently Kyle Quest, CTO and co-founder of CloudImmunity (disclosure, I’m an adviser to the company) wrote a post detailing the results of some research he’d undertaken about the robustness of protocols that cloud vendors use to ensure strong password use. In part his research came abut after a rash of security compromises – from Evernote to LinkedIn, from Sony to Yahoo, a number of supposedly hi quality services showed that the way they go about password use makes them vulnerable to attack. As Quest pointed out, most discussion in technical communities focus on technical solutions – using hashing algorithms, salts for password hashing etc. But Quest pointed out that one of the primary issues here is that these services fail on what should be the first place they ensure security – helping users pick safe passwords. As he pointed out:

When users pick “password” or “123456,” it doesn’t matter how secure the password storage and password hashing are because attackers will guess these passwords in no time. It’s common practice for Internet and cloud application vendors to say that users shouldn’t pick weak passwords. But telling people to pick secure and hard-to-guess passwords simply doesn’t work because in many cases people will pick the easiest password their cloud applications allow

In an attempt to quantify the problem, Quest investigated 130 different cloud services spanning the continuum – IaaS, SaaS and PaaS, consumer and enterprise, technical and end-user. The results were a little depressing, the vast majority of services allowed users to use short passwords and had no requirement for a mix of letters and numbers, uppercase and lower. There was nothing stopping users from registering for a service using that old faithful – password1. He raised the question of whether services, especially those dealing with payments and billing, should enforce stricter password requirements on their users. His conclusions were that for most vendors, passwords are the “elephant in the room”, an issue that’s commonly overlooked. Sometimes developers are afraid to impact the user experience in a negative way, but a lot of times only a bare minimum is done because security is at the bottom of the developers’ to-do list and the user account implementation often ends up being based on the code samples found on the Internet.

The most secure passwords are, of course, random combinations of characters – but the flip side of this is that these passwords, while secure, are very difficult for users to remember. The net result is that users pick passwords they’ll easily recall, and often use the same password for multiple services. People do the bare minimum to meet requirements, this setting up behavioral blueprints that attackers use against them.

The future is more than likely going to consist a large number of discrete services and applications. Application security needs to be seen as a core building block of that future. Ideally that would mean we move from the current status quo of password based authentication but, as Quest puts it, passwords are like roaches, they’ll outlive us all. Instead of living in a fantasy or pretending that the problem doesn’t exist and pushing the responsibility for password security on cloud application users, we need correct password security implementations, and we need innovation to make passwords safe and usable.

Democratizing Development – Where PaaS Should Go

A few months ago I wrote a post that looked at application development, and the existing tools that help bring the ability to develop software to an entire audience that formerly didn’t have the ability. Over the past five or six years I’ve grown increasingly excited about Platform as a Service (PaaS) and its ability to remove some of the more “mundane” aspects of application development and operations from the responsibility of the developer. The traditional view of what constitutes a PaaS, is fulfilled by products such as Heroku, EngineYard and Cloud Foundry – essentially these tools do an excellent job of allowing developers to code their applications, and thereafter run them without worrying about wrangling the practicalities of servers, load balancers, security and the like.

It strikes me however that, valuable as traditional PaaS is, it allows developers to be more productive and efficient, but it doesn’t do much to democratize the actual development process. If the very same people who were creating software before are the ones doing so now, we haven’t really come a long way. Especially not when one considers PaaS is one of the triumvirate of services generally shown in the cloud computing pyramid – along with Infrastructure as a Service and Software as a Service, IaaS and SaaS respectively – cloud computing is all about democratization. SaaS has resulted in businesses being able to do stuff they simply couldn’t before, IaaS means even the smallest startup can now afford world class infrastructure. meanwhile PaaS, as we’ve known it, does great things for efficiency, but little else.

It was this fact that encouraged me to segment the PaaS market into a couple of different categories – Infrastructure PaaS (iPaaS) is the category that covers all of the aforementioned vendors – it allows developers to do what they do in a more efficient way, and stop worrying about the realities of IT operations. Application PaaS (aPaaS) on the other hand is a very different beast. It is a data-centric platform that is tuned to allow average business users to build applications that are centric to the core business data they already use. In the example of Force.com, perhaps one of the oldest and best-known iPaaS vendors, this means that a business analyst can conceivably build an application that is based upon their core CRM data. Of course it goes without saying that all the infrastructure on which this application sits is automatically managed by the platform itself.

This higher level of PaaS really does make a difference within an enterprise. In the old days, a business that wanted to, for instance, create a custom application that integrated with its ERP or CRM, would have needed to engage a developer with a deep understanding of both development languages and the hooks into the software package being integrated with. With aPaaS that is no longer the case. The platform itself is built upon the application and hence is already integrated with the core data the organization is trying to use. The language is easy enough for most business people to use and hence they do, creating applications at will.

Of course there are a couple of problems with this sort of democratization, the first being that “real” developers dismiss these “light weight” platforms as being toys that aren’t for real software development – it’s a similar reaction to that which skeptics gave Visual Basic when it was first introduced. But, in the same way that Visual Basic brought development to a new class of user, so too does aPaaS. The second problem with these sort of aPaaS offerings is that, by definition, they tend to be highly proprietary and hence create a high degree of customer lock in. In this day and age when application and infrastructure portability is garnering widespread attention, highly proprietary platforms sometimes sit a little uncomfortably with organizations.

Which brings us to a new approach, a plain language approach towards application development that doesn’t even feel like development. In recent months, fuelled by the ever increasing plethora of services that are readily integrated by virtue of their public facing Application Programming Interfaces (APIs), we’ve seen the creation of a number of platforms whose very purpose is to allow users to connect service A with service B and create some workflow between the two. The ideas of services such as IFTTT and Zapier, is that they both allow application integration to occur, but that also workflow around the integrations is enabled. While it’s not development in the traditional sense of the word, it’s a definite proxy for some development tasks. Best of all however is that it’s easy for anyone to use – no developer skills needed.

The other direction that development democratization is occurring from is natural language. Recently researchers at MIT reported that some simple tasks – manipulating word-processing documents and spreadsheets – can be manipulated in ways that previously needed programming skills. Even more interestingly the researchers’ methods could potentially prove applicable to more general programming tasks. The researchers used a trained computer system to convert natural-language descriptions into “regular expressions”. In the same way that SIRI manages to understand a common language query and give an appropriate response, systems can begin to translate natural language expressions into code.

The cloud computing cognoscenti continue to obsess on the details – the minutiae of Amazon Web Services‘ latest product offering, or whether OpenStack is going to be the cloud operating system of choice or some other issue of major import to a handful of pundits. Meanwhile there are a massive number of organizations and individuals who simply want to get stuff done, to create applications that meet their organizational needs. These hyper-democratizing development solutions may not have the cachet of the better known options, but their impact is likely to more than make up for that.

 

Mimecast Raises Squillions to Do Something Boring (But That’s a GOOD Thing)

Let’s face it – the technologies that constitute the plumbing underpinning what we do online are boring – but they’re also critical. They may not get the attention of an event like TechCrunch disrupt, they may not tick the boxes of “social”, “mobile” or “local” but they allow our world to function, and perhaps that is more important than the latest app to allow filters to be used with little square pictures. Case in point Mimecast, a company that delivers cloud-based email management for Microsoft Exchange. The services Mimecast delivers include archiving, continuity and security. While being almost entirely invisible, Mimecast has grown to the point where it has more than 6,000 customers worldwide and has offices in Europe, North America, Africa and the Channel Islands.

Luckily (for Mimecast at least) there are people out there who don’t get swayed by the sex-appeal of a product and look at what really matters – the real value a solution delivers. To this point Mimecast are announcing today that they’ve picked up a massive $62M Series C round. According to the company:

Mimecast intends to use the investment to drive innovations in corporate email. The company’s technology has already played an instrumental role in changing the way businesses deploy email; leading the transition from fragmented LAN-based infrastructures to a single platform cloud solution, Unified Email Management (UEM). Mimecast will now focus on continuing this evolution, using its Software-as-a-Service technology to create an Information Banking platform that allows businesses to unlock the inherent value stored within corporate email.

Mimecast as a product is in the same space as Postini (acquired by Google) and also products from Symantec and McAffee (Symantec.Cloud and MX Logic respectively) – it’s an important space as the sheer quantity of email ramps up, and the compliance requirements on originations become ever more stringent. In his comment on the funding, cEo Peter Bauer perhaps indicated where the company will move as pure email archiving become more connected across social and collaboration products:

Today’s businesses are as dependent on email as ever but, increasingly, email struggles to keep up as the way we create, store and share information changes… we believe email needs to be rewired if it is to continue to deliver real value to businesses…. we are working to make email more collaborative and more interactive to realise the true value of the vast amount of unstructured data in email stores. We believe that the future is a more interactive archiving model, where IT folk and end users alike can derive more value in real time, on a day-to-day basis on any technology platform they choose to use.

More than simply tagging the words collaboration and interaction on to a boring product however, this message speaks to an interesting new direction for archiving products – and $62M buys a fair bit of development in that direction. Watch this space.

On Trial Periods for SaaS Companies–Is Shorter Better?

Recently KashFlow CEO Duane Jackson made the decision to reduce the trial periods offered on his product from 60 days down to 14. In blogging about this change, Jackson explained the decision saying;

We analysed our trial data and found that the vast majority of people who never converted from free trial to paid-up had logged into the software only once or twice. It could be argued that this just means they quickly determined the software wasn’t for them and went off into the sunset never to be seen again. Maybe.

But we phoned up thousands of would-be customers and asked why they hadn’t continued with the software – the overwhelming response was “I just never got around to looking at it properly”.

The science of customer acquisition is massively complex, and it’s very interesting seeing KashFlow be so open about their experiment. I have a couple of thoughts around trial periods.

If they don’t start using the product straight away, they never will

I’m a firm believe in the adage that immediacy is everything. I’ve long thought that for many applications an extended trial period only gives prospective customers the ability to put off actually diving in and learning about the software. By putting this off the software remains out of sight. And, as we all know, when something is out of sight it tends to be out of mind. SMBs (the target market for KashFlow) are very time poor and are constantly faced with a deluge of things to do. I’ve seen it happen time and time again that when a task is put off for an extended period of time it has the tendency to slip off the radar and be forgotten. I suspect that a significant proportion of the cold prospects that SaaS companies in the SMB space have are ones who simply “never got around” to trying out the product.

Complex solutions need sufficient due diligence

Accounting solutions, even for SMB customers, have a degree of complexity that shouldn’t be under emphasized. There is a high degree of functionality that SMBs need to assess to determine suitability for purpose. The move to 14 days gives SMBs a very limited time frame with which to try a product and many people would suggest that by limiting this time many users simply avoid signing up at all.

The other issue that is of real relevance for users of SMB accounting software that are migrating from a legacy solution is the significant barriers to migration that exist. Moving from desktop accounting to cloud accounting products is a very difficult process – I’ve been involved in moving 10 or so businesses from MYOB to Xero for example, despite having 15-odd years experience in SMB bookkeeping, and having studied accounting practice, it really is a dog of a process. As an aside that’s one of the reasons that I’m part of a joint venture, LiveMigrate, that offers a migration service from desktop to cloud accounting products – automating migrations is, I believe, one of the the biggest things a vendor can do to increase conversion and uptake.

My suggestions

This is a complex area and their are people who focus exclusively on strategies for sales pipeline management. I don’t purport to be such a specialist and I suspect the majority of SaaS vendors are also not experts and cannot afford the services of these specialists. Luckily there are a range of analytics tools available that SaaS vendors can use behind the scenes to measure this process. In particular Totango is a tool that helps vendors gain an understanding of users behavior resulting from different product offerings, trials and marketing communications to prospects.

The example that some commenters on the initial post gave of prospects who might sign up for a trial only to be cut off after the 14 day free period but before fully assessing the application is a valid one. While not resolving all the issues people brought up, it might be worth KashFlow automating a change whereby trialists that use the application over a certain amount, but haven’t fully made a purchasing decision, are offered an extension to their free trial.

Either way it’s an interesting experiment and I look forward to seeing some more data surfaced about the results.