Today I needed to password-protect a Redmine installation. I’ve typically used mod_auth_mysql for similar projects, but Redmine uses a salted password format that’s incompatible with mod_auth_mysql. So, I turned to Apache/Perl authentication, a first for me (I rarely touch Perl) and was able to make it work.

1. Install mod_perl, and the DBI, MySQL, and Digest (SHA1) Perl modules.

   $ apt-get install libapache-dbi-perl libapache2-mod-perl2 libdbd-mysql-perl libdigest-sha1-perl
   

2. Copy Redmine.pm to the appropriate Perl location.

   $ cd /path/to/redmine
   $ mkdir -p /usr/lib/perl5/Apache/Authn
   $ cp extra/svn/Redmine.pm /usr/lib/perl5/Apache/Authn/
   

3. Perhaps I’m not using Redmine’s projects/members/permissions correctly, but I had to patch Redmine.pm to get it to work for me. I greatly simplified the SQL statement used to authenticate a user. There’s no sense of permissions; it’s simply a yes/no for authenticated users.

   --- Redmine.pm	2011-11-12 17:33:10.000000000 -0700
   +++ Redmine.richardkmiller.pm	2011-11-12 17:37:26.000000000 -0700
   @@ -148,16 +148,11 @@
      my ($self, $parms, $arg) = @_;
      $self->{RedmineDSN} = $arg;
      my $query = "SELECT
   -                 hashed_password, salt, auth_source_id, permissions
   -              FROM members, projects, users, roles, member_roles
   +                 hashed_password, salt
   +              FROM users
                  WHERE
   -                projects.id=members.project_id
   -                AND member_roles.member_id=members.id
   -                AND users.id=members.user_id
   -                AND roles.id=member_roles.role_id
   -                AND users.status=1
   -                AND login=?
   -                AND identifier=? ";
   +                    users.status=1
   +                AND login=?";
      $self->{RedmineQuery} = trim($query);
    }
   
   @@ -336,11 +331,12 @@
      }
      my $query = $cfg->{RedmineQuery};
      my $sth = $dbh->prepare($query);
   -  $sth->execute($redmine_user, $project_id);
   +  $sth->execute($redmine_user);
   
      my $ret;
   -  while (my ($hashed_password, $salt, $auth_source_id, $permissions) = $sth->fetchrow_array) {
   -
   +  while (my ($hashed_password, $salt) = $sth->fetchrow_array) {
   +      my $permissions = ":commit_access";
   +      my $auth_source_id = 0;
          unless ($auth_source_id) {
    	  			my $method = $r->method;
              my $salted_password = Digest::SHA1::sha1_hex($salt.$pass_digest);
   

4. Configure and restart Apache.

   <virtualhost *:80>
       ServerName example.com
       DocumentRoot "/var/www/sites/example.com/public"
       RailsEnv production
   
       PerlLoadModule Apache::Authn::Redmine
   
       <directory "/var/www/sites/example.com/public">
           AuthType basic
           AuthName "Private Area"
           Require valid-user
           PerlAccessHandler Apache::Authn::Redmine::access_handler
           PerlAuthenHandler Apache::Authn::Redmine::authen_handler
           RedmineDSN "DBI:mysql:database=my_database;host=localhost"
           RedmineDbUser my_db_user
           RedmineDbPass my_db_password
       </directory>
   </virtualhost>
   

By the way, I’m running Ubuntu 11.10 (oneiric), Apache 2.2, MySQL 5.1, and Redmine 1.2.2.

I was in Moab this weekend with my family and our motel had free wireless Internet. I used SSH and a SOCKS proxy to create a secure tunnel to my iMac at work. This allowed me to browse Gmail and Facebook securely.

Here’s a screencast on how to create an SSH tunnel and browse securely in Safari and Firefox:

Here’s a full-size video:
How to browse securely with SSH and a SOCKS proxy (full size video)

These are the basic steps on a Mac:
1. Open Terminal. (In your Applications/Utilities folder.)
2. Type “ssh -D 9999 username@example.com”, replacing “username” and “example.com” with the actual username and address of your remote machine. The remote machine will need the SSH service, or Remote Login service, turned on.
3. Open System Preferences -> Network -> Advanced tab -> Proxies.
4. Turn on the “SOCKS Proxy” and enter “127.0.0.1″ and “9999″ in the fields. Click OK and Apply.

Now your Internet connection will be tunneled through a secure connection to your remote machine — a poor man’s VPN.

I’m not a big believer in karma, but this week I experienced some karma-like effects. Two years ago for work, I developed code to protect wiki websites. Then I published it on my blog.

This weekend a software upgrade caused this protection code to stop working on our websites. I couldn’t find an answer. Then yesterday, some chap named Nathan left a comment describing the solution. I hadn’t asked for help. He was simply documenting his own experience. But it was just what I needed.

This is fundamental to open source software — the creation of a software commons. It’s also what happens on Wikipedia, the creation of a knowledge commons.

In Love Is the Killer App, Tim Sanders suggests freely sharing your knowledge and your network, not hoarding them.

Jon Udell talks of “narrating” one’s work from day to day. This allows everyone to share in your vast brain knowledge, and it becomes your living résumé. I’d like to do more of that.

You’ve heard over and over the importance of choosing a good password, but we all seem to keep the same bad habits. Roger Grimes analyzed 34,000 real passwords and discovered some interesting trends:

• As expected, English vowels are by far the most frequent occurring password symbols.
• [In passwords with numbers,] the number 1 appeared 45 percent of the time, followed by the number 2 (22 percent.)
• The exclamation point was the most commonly used non-alphanumeric character.
• Words, colors, years, names, sports, hobbies, and music groups were very popular.
• Other popular words include: angel, baby, boy, girl, big, monkey, me, and the.
• Names of sports — golf, football, soccer, and so on — were as popular as professional sports teams and college team nicknames

Drawing on this study and other wisdom, here are some tips for choosing a good, secure password. Read #8 if you don’t read them all:

1. Don’t write your password on a sticky note attached to your monitor (or “hidden” under your keyboard.)
2. Don’t choose anything obvious like your birthday, spouse name, etc.
3. Don’t choose any single word you can find in a dictionary.
4. Don’t use the same password on a secure site (like your bank) as on an insecure site (like a mailing list.) If someone discovers your password because it was emailed to you from an insecure site, you don’t want your bank account to be vulnerable. Ideally you’d keep a different password for each site.
5. If a digit is required in your password, don’t simply append a “1″ or a “2″. If a symbol is required, don’t simply append an exclamation point.
6. Learn which channels are secure and which are not. Generally HTTP, FTP, and VNC are not secure, while HTTPS, and SSH are secure. Don’t use secure passwords on insecure channels. (Look for the padlock in your browser.)
7. Pick a password you can remember, so you won’t have to write it down.
8. Pick a LONGER password. Think of a phrase or sentence or haiku, not a word. Password length is more important than symbols or numbers. For a security expert like Mr. Grimes, a 6-9 character password with “complexity” (symbols, numbers) is fairly easy to break, while a password with 15+ characters is almost impossible to break.

Eventually, we may be using our fingerprints or some other biometric procedure, but until then, choose a good password.