https Can Wait - SaaS Needs Better Authentication First

Twitter just got burned in the cloud. Some "hacker" managed to figure out a password to one of Twitter's Google Docs accounts. This guy went on to send a whole slew of confidential Twitter documents over to TechCrunch.

This kind of stuff happens all the time, but our collective Twitter obsession has catapulted this story to the top of the news. Twitter's role in the recent Iranian protests has given the fledgling service a new gravitas. An attack on Twitter, it would seem, is an attack on all of us. And to make things worse this was a direct attack on cloud services. This perfect storm even has the New York Times talking about cloud security.

First let's look at what actually happened. An administrative assistant at Twitter used the same password for her corporate Google Docs account as for a whole bunch of personal services. Enter some guy going by the name Hacker Kroll. He managed to reset her password by answering her "secret questions" and reviving a defunct hotmail account the assistant had given for password reset. A bit of Googling and voila - all the company's goodies from secret business plans to personal emails are in the public domain.

Reading over the chain of events, it seems like this could happen to pretty much any company using SaaS (which according to various studies means most companies). And it raises an uncomfortable question - can Google Docs be trusted for anything truly sensitive given the flimsy password authentication it relies on? For the average user, Citibank password=Amazon password=Salesforce password=Twitter password=Hotmail password=...you get the point.

The Inevitability of Password Recycling

So who is to blame for this gaping security vulnerability?

Let's start with who is not to blame. Users can't be blamed for doing what comes naturally. And in fact, sticking to a very small number of passwords makes sense from an availability perspective. The security risks arising from using the same passwords everywhere pale in comparison to the total catastrophe that ensues from actually getting locked out of accounts. The average user would rather risk a 0.01% chance of their online accounts being compromised than a 5% chance of being locked out of their accounts (OK, I'm making those numbers up but you get the point).

There is another reason not to blame users - they haven't been given any workable alternatives to password recycling. Users are justifiably nervous about browser-based password managers - it opens up a Pandora's box of cross-site scripting and other vulnerabilities, no matter how complex your passwords are. And systems like KeePass that allow users to store their passwords in encrypted form may be very convenient for a paranoid minority, but just don't meet the real world needs of the average user.

Some companies try to force unique passwords through complexity requirements or password expiration policies. These settings aren't always available (Google Docs doesn't allow password expiry) but in Salesforce for example these settings can be set administratively. But this still doesn't solve the problem of password recycling. If a given user has hundreds of pictures of their golden retriever on Facebook and all of his passwords are goldenretriever1, goldenretriever2, etc, there's no configuration setting in the world that's going to pick up on this.

So the solution isn't going to come from user education or unenforceable corporate policies. SaaS providers need to offer more secure cloud authentication alternatives, even if this means charging a premium. SaaS vendors will of course only react to a market need. Unfortunately there has been very little pressure on vendors and the focus to date has been disproportionately on old fashioned network security issues. This has come at the expense of improving the very weak authentication structure in place in most SaaS offerings today.

https and Barking Up the Wrong Security Tree...

Take for example the recent letter to Google from a group of security industry thought leaders calling on the company to enforce https rather than http. While that is a worthy goal, it builds on the security industry's https fetish while ignoring the much more significant cloud authentication crisis.

Defaulting to https protects against packet sniffing; an important security objective, but one that is less critical in the cloud than on corporate networks. Compared to guessing passwords, running a packet sniffer requires a high level of technical expertise and a high level of direct network access. The rewards are also limited - sniffing a Google Doc that is being transmitted in plaintext gives access to that one document. Compromising a password yields the mother lode. That's why the majority of attacks we hear about involve guessing user credentials, not performing network monitoring (the TJMaxx case notwithstanding). Nine times out of ten when the media talks about an account being "hacked into", they are not talking about a compromised router or server. They are talking about plain old password guessing a la Twitter or Sarah Palin Yahoo account.

Security risks in SaaS differ sharply from the traditional firewalled corporate network. At the risk of vast generalizations, https is more important than robust authentication in a walled environment, but in the cloud that priority order is flipped. Password authentication is often sufficient protection for in house corporate resources because there is usually at least one more hurdle to climb to actually get at the data. That hurdle might be knowing how to get onto a company VPN or even just knowing the URLs of the company's web facing resources. These aren't state secrets, but probably enough to deter the casual hacker. Remember, the only technical skills involved in many headline-grabbing "hacking" incidents are a bit of Googling and combing Facebook for clues to password reset questions.

Poor password management is of course still a problem within corporate networks, especially for shared passwords. I recently discussed this issue in an interview that was published in Computerworld today. The lack of administrative password management is another example of skewed security resource allocation; organizations that spends enormous sums on firewalls, IDSs and other network security devices and services often fail to properly secure system access accounts such as root passwords on Linux servers, administrative passwords in Windows, or sa passwords on databases. Indeed the lack of proper management of administrative passwords was apparently yet another security issue at Twitter.

But the shift to cloud services like Google Docs gives potential hackers an even lower hanging fruit than guessing at default or poorly chosen administrative passwords. Cloud computing increasingly means that the only thing standing between a hacker and confidential data is a single password. After all, there's no point in trying to gain access to a core router with a potentially stupid password when you could just guess away at docs.google.com and try your luck there. And as an added bonus to the password-guessing approach, the lucky guesser gets all the data served on a silver platter, all formatted and ready to go. No messy databases to sift through and no need to have any knowledge of SQL, IOS, or other unpleasant technicalities.

Adding Just a Bit of Security to the Cloud

Eliminating the all-you-need-to-do-is-guess-a-password vulnerability in cloud computing isn't rocket science. It is in fact much easier to address than the politically dicey issues involved with shared administrative passwords. And there is no reason SaaS providers can't charge for the service. SaaS providers such as Survey Monkey already offer https versions of their products at a cost. Incidents like the recent Twitter snafu will push mainstream SaaS providers to offer premium authentication services as well.

There are a couple of easy-to-implement solutions that would have prevented the Twitter hack and also the vast majority of other SaaS password-guessing attacks that have been going on lately. One method is to require an extra "corporate password" to get into an account, so that employees need to enter both an individual password and a second password maintained and periodically changed by the company. Not a perfect solution, but one that would deter the flood of amateur attacks that SaaS seems to attract.

There are other more robust methods to beef up security - users can be required, for example, to submit corporate email accounts as their back up accounts. Another option is to force users to dial into a corporate center to reset their password. They can be then be subjected to much more detailed questions to authenticate them.

Letting companies insert themselves into the authentication process will do a lot more than https to secure cloud services. There just aren't that many folks out there running Wireshark in hopes of stealing a spreadsheet off of Google Docs. As the recent Twitter breach indicates, there are many more people out there trying to guess your employees' maiden names and get to passwords that way. That's not to say that https isn't important. But it's much more important to beef up authentication first.