Transmiting logon information unsecured in the network

Published: 2010-07-24
Last Updated: 2010-07-25 04:02:44 UTC
by Manuel Humberto Santander Pelaez (Version: 1)
5 comment(s)

There is nothing new on the issue of unsecured sensitive data traveling across the network in plain-text. In fact, many popular websites use SSL to crypt information because they became aware of the man in the middle attack, so owners secured their webpages to avoid the attack.

Unfortunately, there are many companies that thinks nothing will happen if they use plain-text to send logon information. You can say there is no problem with hashed passwords, but they are not enough. Rainbow tables are widely used so if a hash is grabbed from the network, it will be cracked in no time.

Delivering SSL and authenticating both ends might be a cheap and reliable solution for this. Yes, I know SSL is vulnerable to Man-in-the-middlle attacks, but it you authenticate certificates on both ends and pay attention when something like this appears, the risks is adecuately minimized:

SSL Error 

How many of us have clicked directly into continue to this website without paying attention on what is the error in the certificate?

I have seen universities where students capture professor's usernames and passwords and start to sell grade changes. I have seen many hijacked e-mail accounts on ISPs that doesn't crypt logon information.

These controls are easy to deploy: IIS has SSL client certificate authentication and  Apache also implements it. If you use all the available security functionality you have in your IT infrastructure, you will minimize many information security risks like this one.

-- Manuel Humberto Santander Peláez | | | msantand at isc dot sans dot org

5 comment(s)


I've observed in the workplace where someone had changed the clock by several years, so SSL connections were triggering warnings like this one. An employee had skipped right through and logged into the business PayPal account regardless. Had it have been a MITM attack of some kind, they would have done the same thing, and given up their account password to the attacker.

Implementing SSL for login to web applications is a good start, but user education becomes the next security risk.

In some environments I'd consider disabling the user from proceeding past the SSL warning, which is probably configurable in some browsers.
The wording at the top of the IE page telling what is actually wrong is not emphasized or bullet-pointed in any way to draw attention to it; it's just there and the regular user doesn't even notice it. All they know is they're supposed to go to this website, so they do. Heck, I didn't notice the wording either for a long time. I still go to Firefox for the actual details because of Microsoft's dumbed-down error messages.

Another good question is why Windows Update does not force new root certificate downloads.

And even worse, I used to work for a company that used self-signed SSL certificates internally but did not distribute the root certificate to anyone, so it was normal behavior for people to click through the warning.

And some of their applications used Java components where the code-signing certificate was expired either because the product was no longer supported or the company didn't want to spend the money to upgrade it.

I had to argue with one major security company vendor that they were distributing applets in their remote access client that had expired code-signing certificates. I finally got someone on the phone who knew what I was talking about and walked them through showing the warning. Turned out they had disabled certificate checking on their own computers and didn't even know it.

We're pretty good about this at my current employer, but we need to connect to a large number of local, county and state government websites for document retrieval. You can probably imagine how many of them are distributing Java and ActiveX document viewers with expired code-signing certificates or simply unsigned code.

And please don't get me started on how many companies think that they are secure by running their website on a "proprietary port" even though the traffic itself is not encrypted. We are arguing with one nationwide bank on this right now.

Sometimes we're our own worst enemy.
Implementing SSL certificate authentication is far from being as easy as enabling the option in your we browser. In many case, it's simply not a usable option outside your enterprise given the complexity in managing these certificates and even when it's actually feasible, the costs in implementing that simply is too high to justify. Also, these technology are usually very hard to move from one system to another so the end user usually requires multiple certificates, adding to the costs and complexity.

Let's take your example: someone on an EDU the network is stealing teacher's credentials. Your options are:
- Use server-auth SSL only and educate the user so that they will be paying attention. It's cheap to implement but it has a quite high user education cost and works poorly.
- Move to an alternate authentication technology: client-side certificate, two-factors authentication, one-time passwords, etc. It's more expensive to implement and has pretty much the same user education cost as the first option. it also requires additional management for losts credentials/authenticators. It's quite effective, though.
- Use alternate technique to catch the perpetrators: plenty of methods can be used (from network analysis to good old "real world" investigation techniques). It's a bit expensive but you have to do most of it anyway for all the frauds that do NOT involve sophisticated traffic snooping.

I don't know for you, but if I was in the pants of an EDU network, i'd first try with option 3 before trying out the more elaborate options.
As far as I know in IE you have to proceed in order to get more information on the cert error. Doesn't it seem odd that you need to perform the option "not recommended" in order to find out more?
I would not say it is far from being easy. Sometimes it is presented as being easy, it is not. It is easier if the CA and intermediate signing certs are preloaded and many are, but not all. You have to pay attention to proper implementation, expiration dates, revocation lists, etc. Many US DOD sites don't get it right, same with many .gov ( is OK for now). DOD CA certs are not preloaded, you must download them and install on your own. The SSL for and which redirects to the former, uses an cert.

It's more commitment than skill to get it right. Even for end users. It can be more complicated to use facebook.

Diary Archives