Twiki and 8 character passwords

At university, TWiki is a pretty common software. At least at the second Google search results page (for “twiki” as search term) I can see some twiki running at our university’s webserver. TWiki is written in perl and I will refer to the deprecated 4.1.x version which was my test system. I got annoyed by limited security for passwords. Passwords are limited to 8 characters.

Login Managers

During installation you will face a select field like this (in the “Security Setup” section):

Twiki Loginmanager in Installation

All those selections refer to different password management backends. Twiki::Client::ApacheLogin is implemented by /twiki/lib/TWiki/Users/ and Twiki::Client::TemplateLogin is implemented by /twiki/lib/TWiki/Users/ In /twiki/lib/TWiki/Users/ the interface is defined. You can check out funny source code sequences like this:

86 —++ ObjectMethod checkPassword( $user, $passwordU ) -> $boolean
88 Finds if the password is valid for the given login.
90 Returns 1 on success, undef on failure.
92 =cut
94 sub checkPassword {
95 return 1;
96 }

Well… this is our interface. Let’s have deeper look into the implementation.


ApacheLogin uses the Apache interface to send 401 HTTP Status codes. If the client receives one of those status codes, a Username and Password Dialog pops up.

Password Dialog for 401 Status Codes

Using this dialog, the login information will be sent to the server. Using a loop in perl, we can print out what the server receives as CGI variables (the ones defined by the server and given to the perl interpreter). I have put the following source code into /twiki/lib/Twiki/Users/ subroutine new (don’t forget to include Data::Dumper).

my $key;
foreach $key (sort(keys %ENV)) {
print STDERR Data::Dumper->Dump([ $ENV{$key} ], [$key]);

From the Apache log, we will get the following information.

HTTP_COOKIE = 'TWIKISID=d00fe404e65832f9d95658d6d9112bec';, referer: /twiki/bin/logon/TWiki/TWikiRegistration
REDIRECT_REMOTE_USER = 'LukasProkop';, referer: /twiki/bin/logon/TWiki/TWikiRegistration
REDIRECT_STATUS = '401';, referer: /twiki/bin/logon/TWiki/TWikiRegistration

Actually I was looking for REMOTE_USER, which is a CGI variable only defined when Authorization was done. The cookie is not really interesting, but REDIRECT_STATUS approves that auth was done. REDIRECT_REMOTE_USER seems to be REMOTE_USER I am looking for… in some way. Alright… so what do we have here? Well… password and username associations are tested automatically by the Apache server and perl will not receive the password itself. Perl can assume that auth was done successfully and does not recognize it any further. Alright. So we have to determine where the passwords are stored.

Passwords for mod_auth are stored in .htpasswd files. A small UNIX find will return /twiki/data/.htpasswd. This file is updated for each change by the perl script.


So the password is stored as a hash associated with the Login name and the local user name. Now let’s come to our real topic: Passwords with more than 8 characters. Let us create some additional accounts.

Username Password
KarlOrff 1234567
CamrinaBurana 123456789
DiesIrae 123456789123456789
SixteAjoutee 123456789123456780

Well… our .htpasswd says:


Now let’s log in with various accounts. As far as Twiki does not support a Logout button, the most comfortable way is to delete the cookie (see above) and refresh the page. Now we can see our problem: SixteAjoutee and DiesIrae can log in with each other ones password. The strange thing is, that their hashes are different. Our source code journey goes on…

Violation of second-preimage resistance?

$TWiki::cfg{Htpasswd}{Encoding} = 'crypt';

Our configuration file at /twiki/lib/LocalSite.cfg defines a variable for the various encoding algorithms. Of course such a variable is a perfect name to search for. The configure uses this variable, but is the only other file.

The file encrypting the password is at line 134. This file will apply the crypt function with a random salt to the password. The salt is 2 characters in length and stored at the front of the actually stored password. A small test script reveals the truth:

print crypt("123456789123456789", "Ut") eq "UtCp6NoUsQdaQ";
print crypt("123456789123456780", "R0") eq "R07ipKyeiYlho";

So there we have our problem. crypt uses the DES algorithm from the operating system and is limited to an input of 8 characters.

print crypt("12345678B", "Ut") eq "UtCp6NoUsQdaQ";
print crypt("12345678A", "R0") eq "R07ipKyeiYlho";

The collision-free solution

Of course the algorithm is the problem and a selection of another algorithm like sha1 (nope, no MD5!) would solve the problem. We do not rely on the operating system or missing implementations of other crypto algorithms.

#!/usr/bin/perl -wT

require MIME::Base64;
import MIME::Base64 qw( encode_base64 );
require Digest::SHA1;
import Digest::SHA1 qw( sha1 );

sub get
my( $passwd ) = @_;

my $encodedPassword = '{SHA}'.
MIME::Base64::encode_base64( Digest::SHA1::sha1( $passwd ) );
$encodedPassword =~ s/\s+$//;
return $encodedPassword;

print get("1234568B"), "\n";
print get("1234568A"), "\n";

This program returns two different hashes:



How can thousands of user accounts be migrated to another algorithm? As far as the hash is stored as a one-way encrypted string, the encryption of the real password with another algorithm is almost impossible. I have written a small crypt() cracking program in python (sorry, Perl 😉 ), but of course it is way too slow; even for a single password. So the only solution is to reset all passwords of all users. First call the /twiki/bin/configure script and change the algorithm setting (“{Htpasswd}{Encoding}” in the “Security Setup” section) [0] and secondly, BulkResetPassword will help you reset the passwords for all users. It takes some effort and time, but in the end you will gain a higher level of security 🙂

[0] It is also possible to directly modify the $TWiki::cfg{Htpasswd}{Encoding} line in /twiki/lib/LocalSite.cfg

Twiki and 8 character passwords