How to Protect Sign-On Credentials and Data Across Open Networks

With the growth of online collaboration suites such as Google Apps, protecting data and sign-on credentials across public networks needs to be a priority.

In 2007, logon details for my personal e-mail account were compromised and used to send spam. Although the consequences were minimal (see “User Name and Password Compromised,” below), in an office environment, the consequences could have been more dire. Was there anything I could have done to better protect myself?

Never Assume You’re Secure by Default

The use of notebooks on open networks in airports and cafes poses a threat to information security, starting with users’ sign-on credentials. Although it would be prudent to use smart-card or certificate-based, two-factor authentication, the use of user-name and password-only combinations are still too commonplace.

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 such 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. But 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 identifications and passwords are transmitted in plain text. Enhanced security mode (Figure 1) uses HTTP Secure 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 multiple 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.

Although information cards may not be very portable, it is possible to export cards and transfer them to other machines, and they can be additionally protected with a personal ID 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-name Geneva, which will incorporate a new CardSpace identity selector and let organizations 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, 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 lets systems administrators enforce the use of SSL connections to protect session data. There are password management features along with single sign-on capability in the Premier, Education and Partners editions.

E-mail in the Cloud

The POP3 and SMTP mail protocols 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, more commonly known as Microsoft NTLM, can be enabled to secure credentials but does not encrypt session data.

Figure 6