Transmiting logon information unsecured in the network
by Manuel Humberto Santander Pelaez (Version: 1)
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:
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 | http://twitter.com/manuelsantander | http://manuel.santander.name | msantand at isc dot sans dot org
Comments
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.
Steven Chamberlain
Jul 25th 2010
1 decade ago
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.
JJ
Jul 25th 2010
1 decade ago
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.
Stephane
Jul 26th 2010
1 decade ago
emontag
Jul 26th 2010
1 decade ago
It's more commitment than skill to get it right. Even for end users. It can be more complicated to use facebook.
Scott H.
Jul 29th 2010
1 decade ago