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.

Hacking Obama

What were these guys thinking? Someone somewhere broke into Obama's Twitter account. And for good measure they also broke into Britney Spears' account (the last time I saw Obama and Spears in the same headline was in those bizarre political ads by the McCain campaign).

It takes some serious chutzpah to hack any account belonging to the future Commander in Chief. Why would someone pull off this kind of stunt? According to the Washington Post, Obama's compromised account was used to send some spam involving a survey. Other accounts were used to send out some pretty stupid messages about sex and drugs (which I will not reprint in an attempt to keep this post PG). It seems like Obama's account was spared that fate for some reason, but there are probably some folks in the Secret Service who will nonetheless not be amused by this entire incident.

The prankish nature of the attack makes me think that it did not require much sophistication. According to the official Twitter blog these individuals "hacked into some of the tools our support team uses to help people do things like edit the email address associated with their Twitter account when they can't remember or get stuck." This is the soft underbelly of most web services - you can turn your production environment into a fortress with WAFs and IDSs and what not, but you are only as secure as your help desk.

Password resets are the Achilles' Heel of today's authentication infrastructure. Banks have known this for years and have relatively strict password reset procedures (and in many countries locked Internet accounts can only be reset by walking into a branch) . But banks are in a fairly unique position - they usually have a close relationship with the customer, know a lot about them, and perhaps most importantly operate in an industry where strict security is expected. Services like Twitter are meant to be fun and can't impose those kind of requirements on their customer base. Heck, any one can set up a Twitter account in someone else's name.

It's hard to tell in this case if a back-end help desk server or portal was hacked, or if the logic of the password reset process was exploited. The latter could be done with zero technical skill (a la Sarah "I-met-my-husband-at-Wasilla-High" Palin's Yahoo email hack). Breaking into a server would involve either a lot more technical skill or a poorly configured server. Twitter hasn't revealed much about the breach so it's hard to tell which one it is. They are also still reeling from an apparently unrelated phishing attack over the weekend.

President-elect Obama is the first President 2.0 (who could have even dreamt of something like Twitter when Clinton was in office and Al Gore was just beginning to invent the Internet?). It will be very interesting to see how seriously the authorities take this incident. A failure to track down the criminals would be pretty scary - if the next President's account isn't safe, whose is?

Phishing scam spreading on Twitter

I don't Tweet. Not sure about you, but the answer to "What Are You Doing?" is usually boring, private, or working. I will probably cave in once Twitter hits the tipping point, but I figure we are still a good year away from that.

But Twitter has apparently gotten big enough to attract the attention of phishers. Over the weekend it was hit by a phishing scam that redirected people to a certain twitter.access-logins.com page. At that point it tries to harvest your Twitter login credentials.

I couldn't find any information on how widespread this attack is (previous social networking attacks like the Koobface virus that hit Facebook have had only limited impact). My guess is that a lot of people have fallen for this - phishing is kind of new on Twitter, and the URL could be legitimate. Active Twitter users are receiving so many messages that they cannot possibly check if each one is legit.

What is being done with the login credentials that have been harvested? I have absolutely no idea, but in the absence of hard facts let me venture a guess. Twitter itself could be used for spamming, click through fraud, page rank manipulation and the like. This is annoying for the victim but not much more.

Although most people use the same password for just about everything, I don't think there is a practical way for the Twitter attackers to use these credentials on other sites. This would require a more sophisticated spear phishing approach (a phishing attack that targets a particular person) that this does not appear to be. On the other hand, it would not be difficult to try all the harvested login credentials on say Citibank. But given the early detection of this phishing scam and the relative tech savviness of Twitter users, the impact of any such attack would be limited.

There's not a lot that can be done about these kind of attacks. Even careful users who are aware of phishing scams can easily fall victim.

A few quick lessons for security managers from this:

• Emphasize the separation of work and personal email. This will help limit the damage if one of your employee's personal email accounts is compromised.
• Enforce password complexity and expiry. This reduces the likelihood that employees can use the same password universally.
• Make sure that phishing is part of your information security training. Remind employees to be careful where they enter their credentials.