NIST, the National Institute of Standards and Technology, has given the thumbs down to TKIP, the encryption algorithm in WPA. This isn't to say that TKIP is weak or that any particular flaws have been found in it, but rather that a replacement for TKIP has already been found and approved by NIST. AES, which is supported by an increasing number of manufacturers, is the NIST standard for data encryption. NIST rightly figures that if they've vetted AES, and AES equipment is available, there's no need for them to bother with TKIP.

The moral of this story if you've got TKIP-only equipment right now, no need to throw it out. You're still safe. In the future, when looking for Wi-Fi equipment, you might want to choose models that also support AES.

By spring of next year, the Wif-Fi Alliance will be requiring all equipment that is to be Wi-Fi Certified include WPA2 support.

This is a good thing. It forces manufacturers to stay current with the latest security standards if they want certification. I don't think we would have the anywhere near the same level of WPA adoption today if the Wi-Fi Alliance hadn't been requiring it since late 2003.

Microsoft recently got busted for its flawed use of RC4 in Office documents. They are encrypting different data with the same key and initialization vectors, which is a big no-no, particularly when using a stream cipher like RC4. The vulnerability is very similar to the one that brought down WEP — an RC4-based system that suffers from initialization vector issues. It is, shall we say, "unusual" to use a stream cipher as a file encryption algorithm, but not necessarily a problem if done correctly. What is most galling with this flaw is that, as Bruce Schneier points out, Microsoft had the exact same flaw in a different component five years ago. History repeats itself.

My main issue with the article itself is the subheading: "Microsoft should sort flaw and abandon RC4 in favour of better ciphers, says PGP creator." RC4 is not a bad algorithm per se, you have to be careful about how you use it (which is true for any crypto algorithm). WEP uses RC4 in a flawed manner, but WEP's current replacement, TKIP, also uses RC4, and has (as yet) proven to be strong.

Wired has a fascinating article on a Dutch lock-picking competition. There are a lot of parallels between traditional physical security (like locks) and computer network security. My favorite quote from the article:

Tobias' two volume book, Locks, Safes and Security: An International Police Reference is $219.95. I'm working on a justification for buying it.

And you thought regular cell phone ring tones were irritating: some intrepid entrepreneur has recorded ring tones featuring a moaning porn star. What I really want is the Tasmanian devil ring tone.

Chris Holland posts a rant on The Apple Blog (a blog about Apple, not by Apple) regarding the relative security merits of Mac OS X and Windows. While I generally agree with his conclusion that Mac OS X is the more secure operating system, I disagree with the way he arrives at that conclusion.

To begin with, he asserts that because Mac OS X doesn't have any services enabled by default, it is immune from network attack. This is mostly true -- if BIND isn't running on your machine, then any flaw in BIND cannot be exploited. Saying that no services are running by default isn't to say that the network stack is disabled, however. Flaws in the kernel TCP/IP stacks could still be exploitable with all services disabled. For instance, a buffer overflow in the ICMP echo service could be exploited by simply sending a specially formatted ping. This isn't to say that Mac OS X is vulnerable to this particular attack, but rather to illustrate that disabling your services is a false sense of security.

The fact that Apple makes it very easy to enable the by-default disabled services doesn't bode well for security. Given that there have been a number of remotely exploitable vulnerabilities in the Mac OS X sharing services (Apache, Samba, OpenSSH, et. al.), you will not be safe unless you never turn these on. I don't subscribe to the "turn your computer into a lead weight" school of security, so somewhere there has to be a compromise between usability and security. All that said, I do agree with Chris that the services should be disabled by default; let the user make the choice to enable them, even if it is an uninformed choice.

Chris also goes after the Windows software update mechanism because it uses Internet Explorer as its host. I'm somewhat unclear on his argument that running the software update mechanism as a separate application is somehow more secure than running it in a browser. In my experience, any code running on your machine is just as vulnerable as any other code, whether it is a web browser or not. And while you can still manually point your browser to windowsupdate.microsoft.com and update your system, if you are running any somewhat recent Windows operating system there is a separate application that periodically checks for updates and asks for your permission to install them. This is nearly identical to the Software Update application in Mac OS X.

There seems to be this belief out there that Mac OS X, because it has suffered from very few instances of malware in recent years, is somehow invulnerable. It isn't. It's simply a much smaller target. Hackers spend their time trying to hack Windows because the rewards are so much greater. If as much effort went into exploiting Mac OS X as goes into exploiting Windows, we Mac users would be in for a world of hurt. If you plug your computer into the internet, you'd better be safe. The fact that you are using Mac OS X may make you safer from network threats, but it does not make you immune.

Paul Day has a great paper describing a number of techniques for securing your Mac OS X installation. I prefer his approach to security to that described in the NSA's Mac OS X security guide. More of a "turn off everything you don't need and securely configure what you do need" approach versus "turn everything off, because if your computer is a lead weight then no one can hack it" approach. It's all part of the compromise between usability and security.

I don't really care about being able to use VNC to access my Mac from my PDA. What I really want is a wiener dog in a Superman cape.

I love Susan Bradley's Windows SBS weblog, which is why I've made frequent links to it from this blog. On this post, however, I have to disagree with her. She suggests that if you don't want your website (or portions of your website) to show up in Google, you need to create a robots.txt file.

In fact, what you need to do is implement some form of security for your website. Google and other well-behaved search engines may honor your robots.txt file, but others will not. The robots exclusion file provides some obscurity, but no real security. With IIS, you can set up directory security using the Internet Information Server configuration application, for Apache, using .htaccess files. Requiring a username and password will keep everyone (well, with the usual caveats about no security system being foolproof) from getting to your "under the radar" website.

Why does this make perfect sense to me while this scares me? Man, I hate NT shell scripting.

And while discussing shell scripting, it is true that Microsoft Windows Services for Unix is available for free, but so is Cygwin, which is much more comprehensive.

iDefense has identified a vulnerability in the remote administration facility of the 3Com OfficeConnect Wireless 11g Access Point that can allow an attacker to take control of the access point. Or, at a minimum, recover the access point's SSID and WEP keys, allowing the attacker full access to the wireless network.

3Com has a fix available. If you're running one or more of these access points, you should update now.

Immunity, Inc. has found several exploitable bugs in the Mac OS X kernel [PDF]. They allow a local, unprivileged user to escalate their privileges to root level. These are local security holes, meaning that a local user must be able to execute code on the vulnerable machine in order to exploit the holes. Not as serious a problem as remote security holes, but serious nonetheless.

The fixes are trivial, so I would expect to see an update from Apple shortly.

My favorite part of the security advisory? The disclosure paragraph:

Looks like its dog-eat-dog in the security advisory business!

CNN> has an article on Wi-Fi network spoofing. Basically, an attacker sets up an access point in the range of a legitimate network, and configures it to have the same SSID as the legitimate network. Users expecting to log in to their regular network instead get the attacker's network, and the attacker can trivially capture their passwords, read their email, see what web sites they visit.

To protect against this, users can enable WPA on their Wi-Fi networks. At a minimum, WPA Personal requires a password shared between the client and the access point. During the authentication process, a handshake occurs that requires each end of the connection to prove to the other that they know the password (without sending the password, of course). An attacker with an illegitimate access point presumably won't know the password, and any attempt to connect to that access point would fail.

Even better, WPA Enterprise uses a TLS handshake between the client and the authenticating server (such as Elektron). This means that the server uses a digital certificate to identify itself to the client. If the server can't product a certificate trusted by the client (as would be the case with an attacker), the client won't connect.

Susan Bradley (the "SBS Diva") has another good point about Windows security. In this one she elucidates the difference between local (i.e., Built-in) administrators and domain administrators.

At the last company I worked, the standard policy was to give each user administrator access to their own machine, while reserving domain administrator access for sysadmins. If I were assembling a network today, the age of viruses and spyware, I don't think I would give users quite so much leeway. 99% of what most users do with their computers does not require administrator-level privileges, and having a user run with administrator-level privileges means that every application that user runs has administrator-level privileges. Since most applications don't (or at least, shouldn't) require such privileges, there's no reason to grant them.

Now, in the interests of disclosure, the Elektron configuratoin application requires administrator privileges in order to run. This doesn't really contradict what I've been saying, though: since your are using the application to administer your server, it's not unreasonable to expect it to require use by an administrator. In fact, you wouldn't want just any user to be able to change passwords or do other security-related damage.

There's a new web site devoted to the Mac Mini. At MacWorld Expo last week I had more than a few Mac network administrators tell me that they were ordering multiple Mac Minis to use as servers. Bump up the stock memory configuration, and a 1.25 GHz G4 machine can be a pretty effective mail, RADIUS (of course!), DNS, DHCP, et. al. server. We've got an old 400 MHz G4 here that functions as our primary server, and performs all of the above functions as well as being our bug tracking and source code control server — and it's plenty fast.

A shelf full of Mac Minis is a good intermediate step until (if and when) Apple decides to create XServe blades. It's also a great way to ensure continuity of service if one of your servers gets hacked. If you keep your web, email, and DNS servers on separate machines, if one goes down, the others stay up. And given the inexpensive price of the Mac Mini, it's not unreasonable to buy a couple of extras and keep the around for quick swaps in case of a hack or hardware failure.

The Register has a, ahem, skeptical article describing the new RF-blocking paint from Force Field Wireless.

The company claims that the paint blocks signals from "networks operating at frequencies from 100 megahertz to 2.4 gigahertz" and that it "might hinder the performance of radios, televisions and cell phones". Given that cell phones operate on frequencies between 800 and 1900 MHz (depending on what kind of service you have), shouldn't the paint always hinder their performance? And if your cell phone signal can get out through the paint, how is it that your Wi-Fi signal can't? And what happens when I open up a window? Or leave the window closed, for that matter. Do I need to paint over my windows? What about doors, floors, and ceilings? Yikes.

Personally, I won't feel secure until I build myself a copper mesh Faraday cage a la Gene Hackman in Enemy of the State.

I don't know how old this article is, but it's new to me. The TechNet article "10 Immutable Laws of Security" includes some obvious ones, but they bear repeating.

I'll add an 11th law for Windows users: An unpatched system is an invitation to disaster. It's a corollary to laws 1 and 2: with the frequent occurrence of exploits on Windows systems (and the speed with which they appear — the ever-decreasing amount of time between the publication of a Windows flaw and the appearance of malicious code to exploit that flaw), it is criticial to have automatic updates enabled.

And a 12th law: Don't run any application with privileges it doesn't need. See my earlier post for clarification of why you don't need to surf the web with Administrator access.

It was tiring, but well worth it. Elektron picked up a Best of Show award, and we got a lot of great feedback from folks stopping by the booth. I've got a list of Elektron improvement ideas as long as my arm, and we're going to start working on them beginning today. We've got our work cut out for us, but are absolutely looking forward to it.

In a week of wild speculation and outright hoaxes, FISCHER at RUTGERS comes in with the mother of all rumors: Apple will release a stripped-down version of the Lisa called "MacIntosh".

Microsoft really wants you to upgrade: you can now register online for a XP SP2 CD to be mailed to you at no charge.

Windows XP Service Pack 2 adds a host of security enhancements, most notably Windows Firewall. If you're not on a broadband connection, ordering the CD would be a good way to get up-to-date.

Motorola showed off their new phone that is capable of playing iTunes Music Store DRM'ed music. No pics, or word of when it will be released though. The phone that was demonstrated during a keynote at CES "in many ways mimics the iPod".

Other cool wireless stuff at the show: the Burton Bluetooth snowboard gear. Now I can listen to music in safety and comfort while I snowboard into trees.

Do we really need to surf the web from our cars? At $3495 a pop, I suppose you would really, really need to surf the web from your car to spring for this satellite in-car internet access system.

I suppose if you do end up in a crash while checking your email, you have legal precedent on your side. I'm just hoping that the real target market for this equipment is motorhomes and other RVs, i.e., folks who need very remote internet access in their vehicle while it's parked.

The VC's are partying like it's 1999. The Sacramento Bee has the story the Wi-Fi info portal JiWire (which means "", I learned today) received $2.35 million in venture capital. Having a charismatic CEO is a Good Thing.

Microsoft has released a beta of their AntSpyware product. This is apparently the first fruit of Microsoft's acquisition of GIANT software. The beta is a free download, but I couldn't find a mention of whether or not the shipping software will be free. It really ought to be, given that this software is mostly fixing flaws in Windows.

Despite the fact that there is no such standard, Linksys has announced their first 802.11n products. Faster and with greater range, 802.11n products are also backward compatible with 802.11b and 802.11g hardware. The Linksys, along with Belkin's already-shipping 802.11n equipment, is the start of an avalanche of such equipment.

Wi-Fi Planet has taken a look at DRM schemes for Wi-Fi devices. Looks like Linksys went with DTCP-IP, while D-Link went with Windows Media Connect. Both offer means to prevent copying of digital content as it moves from device to device, but they are mutually incompatible.

The purpose of this type of DRM is to allow content providers to limit the distribution of what they create. For instance, a DVD can be tagged with permissions indicating "you're allowed to watch me, but not to make copies". In order to enforce this policy, there needs to be communications protocol that creates an authenticated, encrypted link between the source device and the sink device (to use DTCP parlance). In this example, the source is the DVD player, while the sink is the TV or other display device.

My prediction: DTCP-IP in a knock-out. With the backers it has (Intel, Cisco, Sony, Toshiba, Hitachi, Matsushita, et. al.) and the relative simplicity of the technology (note, I did say relative), it's the clear winner. Microsoft has even announced future support for DTCP-IP.

Vonage has announced a new Wi-Fi phone compatible with their service. The handset has the phone adapter built into it, so you can use it while roaming on other Wi-Fi networks.

The handset is made by UTStarcom, and is presumably the PF1000 (at least, that's the only VoIP Wi-FI handset that UTStarcom seems to make). It supports WEP encryption with 802.1X authentication. I don't see any mention of how you would use a Wi-Fi hotspot that uses a captive portal; presumably the thing has a mini web browser built-in. The article specifically mentions for-fee hotspots, so there must be some way of connecting.

SSH provides secure remote access to servers, but all the cryptography in the world can't protect against poorly chosen passwords. Lately, there has been a rise in server break-in attempts (and presumably, successes) using brute force. That is, an attacker repeatedly attempts logging in, trying various passwords until one works.

OpenBSD Journal has a discussion about defending against these brute force attacks. Suggestions include changing the sshd port, limiting connection attempts, and requiring public key authentication.

I've considered adding port knocking to our servers to prevent this kind of attack, but haven't yet found the time. So far, using long, non-dictionary passwords with a combination of letters, numbers, and symbols has kept the barbarians at bay.

The Buffalo WZR-RS-G54 got a nice review over on Tom's Hardware. It's pricey if all you're looking for is a wireless access point; it's the nice VPN features that justify the price.

The new Buffalo includes WPA support with AES, and Buffalo's products work great with Elektron.