-
Standard, but braindead implementation
One of the features of OS X Server's LDAP is the ability to disable an account after X failed logins. While this sounds like a great thing to turn on from a security point of view, the implementation has a lot to be desired. I turned this on several months ago and within 30 minutes had to turn it off. The reasons why it is flawed are quite simple.
Let's say you have a VPN, a mail server (incoming and outgoing), a calendar server and a chat server and you have the failed logins set at 4. Let's also say that your mail server and calendar server are accessible outside of your VPN so that handheld clients that don't have a VPN client can get in. Most, if not, all services on the Mac store your password in the keychain and many don't offer you the option to enter it each time (which actually would get quite annoying). Next, let's say you just changed your password using a provided mechanism (OS X server requires an add-on to offer this if you only use the LDAP server without all the other management capabilities). Within a few minutes, your mail client will check for mail with the old password, iCal will check your calendar with the old password, you might be sending mail with the old password, and you login to iChat using the old password. Boom, you just hit your 4 failed logins without you entering or being prompted for your password once.
A much more intelligent way to do this would be to have the 4 failed logins be 4 failed logins with different passwords. So if you tried to login 20 times with the same password, it would only be recorded as 1 failed login. Would this weaken security? I don't think so, but could leave your server open for a denial of service attack. In that case, why not take an additional 10 seconds to authenticate for each failed login? So while it would take awhile to have your login fail, at least you could enter your new password without having to contact your administrator. If your administrator is any bit like me, password resets are not easy.
-
A fix for a broken web site
Today I had to purchase a Priority Mail label off the USPS web site and had a few problems with it. First off, Safari decided to keep eating the sample label. I then switched to FireFox and doing a Save As for the label saved it, but the file didn't end in .pdf, so Preview wouldn't open it even if I forced it to open it. (Yes, Preview should have attempted to decode it.) Once I renamed the file with a .pdf extension, the file opened just fine. Hmmm...what should I do to automate the process?
I remembered that I had a program called Hazel on my machine that watches folders and acts on them. I removed Hazel on my last machine because I was trimming things down (it got bogged down). I created a simple set of rules to change all files that start with com.usps to end in .pdf, open them and then trash them. Now I have to figure out more uses for Hazel as this is a great way to automate things.
-
Inconsistent security
A colleague of mine flew from our main office to the east coast to run a test. As part of the test, he needed a large battery to power some equipment. He had no problems taking the battery on the plane to his destination, but on the way back, the battery not only couldn't be carried on, it was pulled off the plane when it was checked as the TSA wouldn't let it fly. There are 2 issues here; one is that we can't find any regulations prohibiting the battery from flying and second, why was it allowed one way, but not the other?
This kind of inconsistency between airports must drive people crazy. When I travel, I travel with the same set of "gear" and haven't had a problem going through any airport (knock on wood). Now if I had to bring more and varied equipment on different types of trips, this would frustrate me to no end. Years ago when I worked for QUALCOMM, I travelled to a conference and had to take a box of cables with me. This was way before tightened security, but I wasn't taking any chances. I got there early, had QUALCOMM stickers put on the non-descript box and had no problems getting through security. Now, if I did that today, would I get searched and extra scrutinized? I guess it would depend on the airport.
I'm so glad that all the money we've spent on protecting our airports by standardizing procedures has helped.
-
So much for unified security?
I'm on my way back from a trip to Kansas City and as I approached security, I saw that the guy checking IDs was private security and not TSA like I'd seen at every airport I've been to in awhile. As I walk past the ID checker, I see that every security person was from a private company. Well, it looks like in the government's efforts to standardize security at airports, they left gaping holes. The The Aviation and Transportation Security Act of 2001 (ATSA) left the option open for airports, like Kansas City to use First Line Security. This seems like such a waste as the government spent a lot of money to get away from private, inconsistent security at airports.
While I can't say that I feel more or less secure going through Kansas City, I think that the inconsistency sends a very wrong message to the flying public.