Sep 01 2009

Out in the Open

Consider these pointers on how to protect sign-on credentials and data across the cloud when using collaboration suites.

With the growth of online collaboration suites such as Google Apps, protecting data and sign-on credentials across public networks has become an evermore-pressing priority.

In 2007, logon details for my personal e-mail account were compromised and used to send spam. While the consequences were minimal (see “User Name and Password Compromised,” below), in an office scenario, a similar incident could be even more problematic. The e-mail service was hosted by a third party, but was there anything I could have done to better protect myself?

Make No Assumptions

The use of notebooks on open networks in airports and cafes poses a threat to information security, starting with users’ sign-on credentials. It’s often assumed that cloud-based e-mail and collaboration tools are secure by default. Read on to learn about the standard security provisions of popular cloud-based collaboration and e-mail services — Google Apps and Microsoft Office Live — and what you should know before using their services.

Microsoft Office Live Workspace

As you might expect, Office Live Workspace uses Windows Live ID for authentication. Users will be familiar with this system if they’ve ever used Hotmail (now Windows Live Mail) or other services from Microsoft. Previously known as Microsoft Passport, Windows Live ID was intended to provide authentication for all manner of online services against a central database held by Microsoft. However, the concept of any single vendor maintaining such a system, which if breached could give access to multiple sites through a single set of credentials, didn’t go down well with users or service providers. Passport eventually evolved into Windows Live ID, which gives access only to Windows Live and other Microsoft services.

Signing in to Office Live is essentially the same as for Google Apps, but users should be aware that sometimes Office Live defaults to standard security sign-in, meaning that IDs and passwords are transmitted in plain text. Enhanced security mode (Figure 1) uses HTTPS to encrypt IDs and passwords as they’re sent over the wire. Once signed in to Office Live, there is no encryption when viewing or uploading documents over the web interface, but Microsoft is hoping to add Secure Sockets Layer encryption in the future.

Figure 1

Windows CardSpace

One advantage that Office Live has over Google Apps is that Live ID integrates with Windows CardSpace. Part of the .NET Framework and built into Vista, CardSpace manages information cards, which can be created by the user as a form of identification. Information from the card and a site-specific card ID is exchanged with Live ID to be used on a particular site. Once configured, a personal information card (Figure 2) can be used to sign in to Office Live without having to provide a password every time.

Figure 2

A single card can be used to sign in to several sites — for instance, a Windows Live Mail account and an Office Live Workspace (Figure 3) — saving users from having to remember different passwords. Information cards use advanced cryptography to ensure the security of information over the wire. They are used to safeguard against phishing attacks.

Figure 3

The Microsoft Office Live Add-in and Outlook Connector, both applications that integrate Office desktop apps with Office Live services, are not compatible with CardSpace and don’t transfer data using HTTPS after a secure sign-on.

While information cards may not be very portable, it is possible to export cards and transfer them to another machine, and they can be additionally protected with a personal identification number (Figure 4). Live ID support for CardSpace is still in beta, but CardSpace is compatible with any site that works with Open ID.

Figure 4

Microsoft is currently working on the next version of Active Directory Federation Services, code-named Geneva, which will incorporate a new CardSpace identity selector and allow organizations to provide single sign-on facilities that extend to cloud services.

Google Apps

Out-of-the-box sign-on to Google Apps is by user name and password, but unlike Office Live, it is not compatible with Windows CardSpace. Nevertheless, Google Apps has a well-supported marketplace where it’s possible to buy third-party authentication services. On the flip side, Google Apps offers data security through HTTPS, ensuring that the contents of e-mail and documents are encrypted over the wire (Figure 5). Be aware that this feature is not enabled by default.

Figure 5

The Premier edition of Google Apps allows sysadmins to enforce the use of SSL connections to protect session data, and there are password management features along with single sign-on capability in the Premier, Education and Partners editions.

E-mail in the Cloud

POP3 and SMTP were around long before the cloud-computing revolution, and there are still advantages to using a mail client, such as Outlook, to manage cloud e-mail, calendaring and contacts. Most web-based access to cloud services will automatically default to securing sign-on credentials using HTTPS, but this is not necessarily the case when using a desktop application. If you’re using SMTP, POP3 or IMAP to connect to Windows Live Mail or Gmail, be sure to follow the instructions carefully for setting up secure connections.

Outlook supports secure IMAP, POP3 and SMTP (Figure 6). These secure protocols can be used to protect both passwords and session data. Secure Password Authentication (SPA), more commonly known as Microsoft NTLM, can be enabled to secure credentials but does not encrypt session data.

Figure 6

IT Takeaway

Although large enterprises may be able to afford all the trappings of multifactor security solutions and identity management, it’s still possible for organizations to be vulnerable if they don’t understand the implications of exchanging credentials and data across open networks.

If all these technical details are mind-boggling, a simple solution might be to route Internet traffic through an encrypted virtual private network when using an open network, either to your corporate LAN or to a trusted third party, to ensure that your data and credentials are kept secure.