Outlook Web Access (OWA) is incredibly convenient, because it allows users to access their Exchange Server mailboxes from anywhere with just a Web browser and Internet connection. But OWA is extremely vulnerable
In this tip, I discuss the various methods available for protecting OWA against keystroke loggers, as well as their pros and cons. I then explore more secure alternatives to OWA that will still allow remote users access to their Exchange Server mailboxes.
Assessing the risk of OWA keystroke loggers
There are countless Trojans floating around the Internet designed to log any keystrokes that are typed on an infected machine, and then transmit a record of those keystrokes to another machine somewhere on the Internet.
If a user's computer is infected with a keystroke logger, and the user enters a username and password to authenticate to your Exchange Server, that username and password gets logged by the remote computer.
Yes, passwords are encrypted during the authentication process, but the encryption only secures the password as it's sent across the Internet. A keystroke logger logs the password as it is typed -- before it can be encrypted.
Keystroke loggers are also a threat because they have the ability to log the contents of any email messages a user types while using the infected computer. Depending on the nature of your company, this may or may not be a big deal. But you certainly don't want an employee who deals with sensitive information composing messages on a machine that's infected with a keystroke logger.
Combating OWA keystroke loggers
The best solution to the keystroke logger issue is to prevent machines from being infected in the first place. Unfortunately, since a user could potentially be on a home computer or public kiosk, securing the machine isn't always an option.
As such, when you're designing your corporate security policies, begin by assuming that any remote machine logging onto your network is infected with a keystroke logger.
You have several different options for preventing passwords from being compromised by keystroke loggers, or of mitigating the effects of compromised passwords.
Each option has its advantages and disadvantages:
Disallowing the use of OWA gives you the strongest security, but that doesn't necessarily make it the best choice.
Before completely disabling OWA, think long and hard about the tradeoff you will be making between security and functionality. Remember, your job as an IT professional is to facilitate the company's business need, and disabling OWA could have a negative impact on employee productivity.
I recently heard someone propose the use of frequently expiring passwords as a countermeasure against keystroke loggers. Personally, I think this is a bad idea.
For starters, if you try to circumvent keystroke logging by expiring passwords on a frequent basis, you're essentially saying that it's OK for the bad guys to get into your system -- as long as it's only for a day or two. This is flawed thinking.
Let's take it a step further. If remote users have keystroke loggers on their PCs, the keystroke logger isn't going to go away just because you force a password change. Whoever planted the keystroke logger will know about the password change as soon as it goes into effect.
As if those reasons aren't compelling enough, here's one last thing to think about: If you force password changes too frequently, there's a good chance that your users will start writing their passwords down. When that happens, you might as well not even have passwords.
In addition to a username and password, two-factor authentication requires a form of physical authentication, such as a smart card or biometric scan, for example.
Keystroke loggers are ineffective against a two-factor authentication mechanism. While a hacker might be able to steal a password through keystroke logging, that password is useless unless it is used in conjunction with the other authentication factor, which the hacker probably won't have access to.
The big downside to two-factor authentication is that most PCs are not equipped with smart-card readers or biometric devices at this point.
Someone at Microsoft recently presented the idea of requiring two-factor authentication for everything but Outlook Web Access. I am still on the fence about this technique. It's an interesting idea, but it has good and bad points.
This technique lets you control the amount of damage that can be done with a stolen password, while still allowing users to have full use of OWA from any computer with an Internet connection and Web browser.
The main downside is that someone could still use a stolen password to gain access to a user's email. From there, they could read confidential messages, or send messages as the owner of the Exchange Server mailbox.
Another drawback to this approach is the expense of deploying smart-card readers or biometric devices to all of the computers within your company. These devices typically also require you to have an enterprise certificate authority server available on your network.
More secure OWA alternatives
Remote users typically have laptops specially configured to allow them to establish virtual private network (VPN) connections. Remote users connecting to the corporate network through a VPN typically do not access their Exchange Server mailboxes through OWA, but rather through Microsoft Outlook. This means that the IT department must preconfigure the remote users' laptops.
From a security perspective, you won't have to worry about remote users entering passwords into public computers that may be infected with keystroke loggers.
On the other hand, you do have to worry about laptop theft. Some users have a bad habit of configuring Windows to store passwords. If someone were to steal a laptop, they could use any one of many available utilities to reset a user's password. The hacker could then access your VPN using the password stored within the user's profile.
The scariest part is that a VPN connection does not just give users access to their Exchange Server mailboxes, but to any resources on your corporate network to which they have permissions.
An RPC over HTTP connection allows remote users to securely connect to the corporate network over the Internet just like a VPN. The difference is that it only allows users access to their Exchange Server mailboxes, not the entire network. As such, while an RPC over HTTP connection may limit the remote user's productivity in some ways, it is better for your network's overall security than a VPN connection.
Scheduled for release in 2007, Longhorn Server will not directly provide remote users with new methods of connecting to their Exchange Server mailboxes, But it will contain features that you can use to make connectivity more secure. One such feature is Network Access Protection (NAP).
NAP will allow an administrator to define what it means for a computer to be "healthy." For example, a health policy might include updated patches and antivirus signatures.
When a remote user connects to the network, NAP compares the remote computer's configuration to the health policy. If the remote computer is not considered to be in a healthy state, it is denied access to network resources until the appropriate updates have been applied.
Network Access Protection actually exists in Windows Server 2003, but you practically need a Ph.D. in computer science to configure it. NAP has been redesigned in Longhorn Server to make it much easier to configure.
About the author: Brien M. Posey, MCSE, is a Microsoft Most Valuable Professional for his work with Exchange Server, and has previously received Microsoft's MVP award for Windows Server and Internet Information Server (IIS). Brien has served as CIO for a nationwide chain of hospitals and was once responsible for the Department of Information Management at Fort Knox. As a freelance technical writer, Brien has written for Microsoft, TechTarget, CNET, ZDNet, MSD2D, Relevant Technologies and other technology companies. You can visit Brien's personal Web site at http://www.brienposey.com.
MEMBER FEEDBACK TO THIS TIP
I have a comment regarding "Requiring two-factor authentication:"
An easy solution would be one-time password (OTP) authentication which only requires a device not plugged to the computer.
The email I received with the link to this article says "Outlook Web Access is extremely vulnerable to keystroke loggers." Outlook Web Access is no more vulnerable to keystoke loggers than any other Web application, but the effect of a compromised mail server account can have a great deal of impact.
Keystroke loggers are a threat, in specific circumstances. Circumstances that lend themselves to OWA usage, unfortunately.
This article is supposedly specific to issues with Outlook Web Access and keyloggers. But why is OWA anymore "vulnerable" than any other local or browser based application that one may be using where you are apt to enter or type confidential information?
The issues are the same as in the case of people using GoToMyPC on computers at Kinko's in New York City that had a keylogging software installed on them.
Furthermore, none of the solutions --save for "not using OWA at all" -- are OWA specific, either.
It's true that on the surface Outlook Web Access is no more vulnerable to keystroke loggers than any other Web site. Even so, the consequences of having OWA key logged tend to be much greater than that of other applications.
If someone uses a keystroke logger to steal a set of OWA credentials, they gain access to all kinds of sensitive data such as email, calendar entries, contacts, etc. They also have the ability to send email convincingly, posing as the owner of the compromised account.
Therefore, I think it makes more sense to be concerned about keystroke logging in regards to OWA than most other types of Web applications (e-commerce being an obvious exception).
Brien Posey, tip author
Do you have comments on this tip? Let us know.
Related information from SearchExchange.com:
Please let others know how useful it is via the rating scale below. Do you know a useful Exchange or Outlook tip, timesaver or workaround? Submit it to SearchExchange.com. If we publish it, we'll send you a nifty thank-you gift.
This was first published in August 2006