![Close [x]](http://dw1.s81c.com/i/c.gif){kind=small}
The security of an LTPA cookie is of great importance, and it is critical to note that the LTPA cookie is vulnerable to theft as it travels across an unprotected network. Even though the cookie is encoded and it is not immediately obvious which logged-in user the cookie represents, it certainly is possible for a bad guy such as Dr. Notnow to steal every cookie he sees going by in HTTP traffic and try each one of these cookies out. However, it's true that to succeed for any length of time with this diabolical plan, Dr. Notnow would need to monitor the network and continually steal new cookies. While diamonds are forever, a stolen cookie is not good long-term. An LTPA cookie is set to expire after a configured amount of time and is not honored after expiration. Nevertheless, a thoroughly motivated criminal such as Dr. Notnow may have little difficulty to steal cookies repeatedly when they are being exposed on an unprotected network.
Luckily, the bad guys can't win at stealing if you deploy SSL at your SSO servers. You should use SSL (secure socket layer) to encrypt communications between the browser and the server (URLs are accessed via https). If hackers are sniffing the wire, these evil-doers will see only encrypted information going across the network, and will have absolutely no way to capture the LTPA cookie. You should deploy SSL at each server in your SSO environment.
We sometimes hear hard-luck stories from the workplace that resources are lacking. If full SSL deployment and support are deemed impractical due to limited resources, you can consider deploying a reverse proxy to act as a gateway and central point of access into your SSO environment. In a reverse proxy scenario, there is the concept of the "untrusted network" where the user may be located, and the "trusted" network where all the SSO servers are located. In the reverse proxy scenario, all the SSO traffic flows through the reverse proxy, therefore the critical point at which SSL must be deployed is at the reverse proxy itself in order to protect communications to the user's browser on the untrusted network.
Figure 1. SSL with reverse proxy
Unfortunately, if you limit the SSL deployment solely to the reverse proxy, the LTPA cookie is still vulnerable inside your trusted network when passed by the proxy to the backend SSO servers. It is difficult to determine whether or not your trusted network is truly trustworthy. Any environment might have unscrupulous insiders who are lurking and ready to pounce on unprotected cookies. (With unprotected cookies available on the "trusted" network, an unscrupulous insider has the opportunity to accomplish many sinister deeds, including erasing online parking violations records.)
When all is said and done, there is no good substitute for thorough paranoia and excellent security hygiene, including SSL protected connections to your SSO servers.