Amazing spam filter

These days, any site that has comments or lets users send email, must have some type of anti-spam system. The most common type is a captcha challenge. For me, it usually takes 2 or 3 tries (if not more) for me to get a challenge correct. I stumbled upon a WordPress plugin called WP Hashcash that uses a Javascript “challenge” to fight spam. The really cool part is that people that use standard browsers that have Javascript turned on (if you have Javascript turned off, you pretty much can’t see many cool sites), don’t see a challenge and can just comment normally. Automated systems haven’t been trained to actually run the Javascript on the comment pages therefore the plugin marks the comments as spam. The plugin is catching a ton of spam.

This is just too cool to have a system in place that (for now) combats spam without inconveniencing my readers!

Is Apple evil?

Awhile back, I wrote that developers that wanted to write iPhone apps should just deal with Apple and the AppStore approval process as the upside of getting an app in the AppStore could be huge. Well, I’ve read lots of stories about the AppStore approval process and my views have changed a bit. Apple rejecting Google’s Google Voice app and pulling other Google Voice apps really would have ticked me off as it could easily have happened to me. When I created GrandDialer last summer (GrandCentral turned into Google Voice and GrandDialer was basically the first Google Voice app), my only problem getting it in the AppStore was that I had to change the color of the dialpad so it didn’t look like the iPhone’s dialpad. Then the stories about dictionary apps having to get a 17+ rating because you can find bad words in it is just baffling.

I’m not sure I’d want to create an app for the iPhone now without some financial backing as the risk is too great for me to go at it alone. I could spend a lot of time on an app and only have it rejected by Apple with little to no explanation why. Maybe Apple could review the ideas first (yes, I realize that is a huge undertaking), but it could help out developers that want to invest time. Even if developers had to pay some amount for this, it would definitely be worth it.

Am I going to develop for another platform? For better or worse, I really don’t write code anymore. The iPhone platform is great for developing, but the closed nature of the AppStore makes it a crapshoot to develop applications that will see the light of day. Is the Pre or Android any better? I have no idea. The huge success of the iPhone has caused a huge following and lots of applications; if the other platforms were this successful, would they see problems with their stores? Maybe. There must be a better way to not tick off developers as people acknowledge that the availability of apps makes or breaks a smartphone.

The honeymoon is over

Yesterday I wrote about using Passenger (mod_rails) for deploying Ruby on Rails applications. Well, this morning, I ran into my first problems with it. I had reports that WebDAV wasn’t working. After trying a bunch of ideas that I read about, I finally decided to try changing the load order of the Apache modules. I set Passenger to load first and then WebDAV load later. That amazingly fixed the issue; if it hadn’t, I would probably have had to scrap Passenger which would have been a huge disappointment.

Dealing with Ruby on Rails Applications

When I first launched my first web site in Ruby on Rails (RoR) to get my store for ReceiptWallet (based on Potion Store) going, I learned a little bit about performance. A basic RoR application is launched each time a user hits a web site; this, of course, is only for development and isn’t practical for a production site. I opted to use lighttpd and FastCGI which worked well. However, modifying an part of the application required killing processes and restarting lighttd.

As a learned more about RoR and had to deploy more applications, I started using mongrel as we had a bug with lighttd that caused our application to not handle uploads. So I’ve been using mongrel for a bunch of RoR applications on 4 separate servers. Things work OK, but each time an application is updated, I have to either restart all of mongrel or kill individual processes and restart them (if I restart mongrel, non-updated apps get restarted and could disrupt people).

Last night as I was trying to catch up on some of my research (quiet time is only at night and allows me to leisurely do research), I came across Passenger which makes deploying RoR simple. All I have to do is setup the virtual host and point it to the RoR’s public directory and presto; this is in comparison to setting up mongrel with proxies from Apache. In addition, in order to restart an application after I update it, I just do ‘touch tmp/restart.txt’. Wow, that’s easy!

Is Passenger the holy grail for managing my RoR applications? It’s too early to know, but I’m optimistic.

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.

Leopard Server Password Reminder

Leopard Server’s LDAP implementation allows an administrator to set requirements about user passwords, such as length of password, what characters it must include, how often it must be changed, etc. One major oversight on Apple’s part is a facility to inform users that their passwords will expire. Maybe if users login via AFP or using Network Home Directories they’d see a message, but we’re using LDAP for authentication from a bunch of other servers. As I didn’t want to have to remember to remind people to change their passwords, I came up with a script to handle it for me. I’ve seen other scripts out their, but they made some assumptions that didn’t work for us. Our mail server is on a different machine and usernames don’t match email addresses, so my solution had to be robust. The only requirement for my script is that the email address has to be filled in for the LDAP entry. Also you must have some facility for users to change his/her own password. We’re using a WebObjects program we found to let users do this.

You’ll need to change the LDAP server name and the number of days to send out the reminder; we require password changes every 90 days, so I send the reminder seven days before. This is run via a crontab at midnight (or so) each evening.

I’m not an awk master, but this seems to be working fine

#!/bin/sh
datelogfile=/backups/datechange.log
tmpfile=/tmp/passwordchange.tmp
grep -h "changed" /Library/Logs/PasswordService/ApplePasswordServer.Server.log* | awk '{ test=$1 " " $2 " " $3 " " $4; cmd="date -j -f \"%b %d %Y %H:%M:%S\" \047"test"\047 +%s"; cmd | getline day; close(cmd); {printf day " " $13"\n"}; }' | sed s/}/' '/g >> $datelogfile
sort -r $datelogfile | sort -r -k 2 -k 1 - | uniq -f 1 | sort -r - > $tmpfile
cat $tmpfile > $datelogfile

# Walk each line in $datelogfile
# See if the date > 83 days ago. If it is, send out a password change reminder
cat $datelogfile | awk '{ cmd="date -v-83d +%s"; cmd | getline expire; { if ($1 < expire) print}}' > $tmpfile
cat $tmpfile | awk '{test=$2; cmd = "ldapsearch -x -H ldap://ldap.gruby.com -b cn=users,dc=ldap,dc=gruby,dc=com uid=\047"test"\047 mail";  while ((cmd | getline) > 0) {if ($1=="mail:") {newcmd = "echo \"From: it@gruby.com\nTo: "$2"\nCc: it@gruby.com\nSubject: Password Change Reminder\n\nYour password will expire in less than 7 days. Please visit:  to change it.\n\n\nIf you have any questions, please contact it@gruby.com.\n\n\n--\nit@gruby.com\n\" | sendmail -bm -t"; newcmd | getline; close(newcmd); break;}}  }' 

rm -rf $tmpfile

Apple, please add some polish to the LDAP server; adding a little user interface on OpenLDAP is nice, but it isn’t finished. Building in the password change ability and the reminder system would be a good start. In addition, securing it out of the box by making the “require authenticated binding” setting actually work (I’ve ranted about this in the past; this actually makes it impossible for us to expose our LDAP server to the outside world and use it for integrating outsourced services like Salesforce that will do LDAP authentication to our server.)

How not to send a security alert

Today at around 5:30 pm, I received an email from one of our software vendors (I won’t mention their name so that their other customers can apply the software patch) notifying us of a critical security vulnerability. The message looked very official from their support department. It was quite detailed about how to patch it and described the different versions that are still being used. As I’m a bit paranoid about security, I checked the email headers and then became quite concerned about the message.

The vendor made the following mistakes in sending out this vulnerability:

  • The message was sent from a third party mailing list provider so the return address couldn’t be verified.
  • There was a direct download link in the email message; since the message was sent through the third party provider, the link was actually back to the mailing list provider so that it could be tracked. I did click the link and downloaded the file, but didn’t run it. It did come from the vendor.
  • There was no link to a support site to directly download the patch.
  • There was no mention of the vulnerability on the web or in their support forums.

After a frantic message to their support folks, I was advised that it was legitimate and was able to verify that the message came from the vendor. In addition, I was told I could download the patch from the support site (I had never logged into the site before). At the same time that I sent a message to their support, I posted a message on their forums asking about this and before they deleted my message, I received a response with the same concern.

I chatted with the person that sold us the software (a reseller for the vendor) and he indicated that I should apply the patch ASAP which I did. He agreed that this could have been better handled.

I hope in the future, this vendor learns a lesson about how to notify its customers. I’m probably one of handful of people that didn’t just click the link and apply the patch; I guess it’s part of my job to be paranoid about security.

All I can say is wow!

Reluctantly Upgraded

After a few years of delaying upgrading Quicken 2005 to Quicken 2007, I finally had to do it. I’ve been using Quicken since 1991 and have skipped a number of updates because I didn’t need the new features which probably didn’t help Intuit’s on and off again relationship with the Macintosh (my father used to upgrade Quicken every year on Windows whether he needed it or not; I suspect this is the thinking of many Windows users).

Unfortunately, Quicken 2005 has some problems with Leopard and I couldn’t edit some categories. In addition, an engineer that works on Quicken told me last year that I should upgrade because there were some potential data losses with Quicken 2005. Quicken 2007 still isn’t Intel native and will require me to install Rosetta when I get Snow Leopard. The next version of Quicken for Mac won’t have investment tracking, so I’ll have to run Quicken 2007 for a bit longer. If I didn’t almost 20 years of data in it and there was something that could reasonably replace Quicken, I’d jump on it.

More on Registration Schemes

Today I saw an update to Multiplex that I bought as part of the MacUpdate Promo bundle. I went into it, did the update (it uses Sparkle) and found that it was no longer registered. I went back to the original download link and downloaded the new version all registered. It looks like the developers embedded the license info in the Resources directory of the app bundle; so when it gets updated using Sparkle, the license gets wiped out. Wow, brilliant. Stop being clever and just have a reg file or a reg code; it is easier to maintain and it won’t do stupid things like this (yes, if you move it to another machine you have to copy the reg info, but that’s a minor price to pay).