Security Response

Today most of the identity oriented transactions on the Internet are done via plain old HTML forms and, if we're lucky, over SSL. And once again, something that seemed sufficient at first, is showing strain as usage grows. HTML/HTTP ends up providing a pretty clumsy and inadequate way to do identity transactions. It offers a poor user experience and wasn't really designed with security in mind. This has contributed to much of the grief over fraud, phishing, etc. Our primary defense mechanism against such threats has historically been the SSL certificate, but we know users don't read those. We also know users don't look too carefully at URLs (even when they are not obsfucated). Some of the more risk prone sites have...

As municipal Wi-Fi networks begin to roll out, I've begun to notice a trend that isn't surprising, but is still a bit worrisome. Business users are beginning to use the muni Wi-Fi in the office. While the signal doesn't often penetrate too deeply into buildings, conference rooms and window offices seem to get a sufficient signal in many cases. The problem is that I see people using the muni Wi-Fi signal instead of the office IT-supported network. Sometimes they just use it because it's more convenient. The office IT network is "secure" and requires extra work, such as entering keys or using a VPN. Sometimes they do it because they explicitly want to avoid the local IT policy controls (access to restricted sites, use of restricted applications, etc.)

So, why is this a problem? First, it exposes the user’s computer to the Internet without the normal protection of the office IT security safeguards (like a firewall). While it's quite possible to...

In a previous blog I wrote about security in municipal Wi-Fi networks and talked about what I called network identification. I wanted to talk a little more about that now. I think this is actually one of the hardest problems to deal with.

Just to recap, the problem is that when you attempt to connect to a wireless network, you do so based on the network name (the SSID). That name, however, is a very poor identifier. The administrator of the access point can name it whatever they like. So, if I want to setup an access point and name it "GoogleWi-Fi", I can. And now when anyone in range attempts to connect to a wireless network they will see one called "GoogleWi-Fi". So, how do you know who you're connecting to?

People have suggested a number of approaches. I've heard some suggestions around educating users...