Secure login

When logging into eprints, both username and password travel openly. Usually it is not a problem as eprints has its own authenticating mechanism, and stealing an eprints password gives the intruder very limited power. However when using centralized authentication (e.g., by LDAP) then protecting the password is more important. To prevent sniffing login pages usually use secure connection. Here we discuss an easy way to set up eprints to use encoded password traffic.

The idea

Change the destination of the eprints login page to a secure host. On the secure host a script receives the data: login name and password (and maybe others), encodes it, and forwards the request with the encrypted data as payload to an unencrypted eprints page. The eprints page decrypts the data and uses it for authentication.

Requirements

You need a secure http server on the same main domain as your your eprints server. For example, if eprints can be reached on the web address http://eprints.umb.edu, then the secure server must have domain name ending with umb.edu, for example https://secure.umb.edu.

You should set up a cgi executable directory on the secure host. The apache config extract below does exactly this so that https://secure.umb.edu/eprints/whatever requests the script /opt/cgi-bin/eprints/whatever to be executed:

<VirtualHost *:443>
 DocumentRoot "/opt/secure"
 SSLEngine on
 ScriptAlias /eprints/  /opt/cgi-bin/eprints/
 <Directory "/opt/cgi-bin/eprints">
     AllowOverride None
     Options +ExecCGI -MultiView +SymLinksIfOwnerMatch
     Order allow,deny
     Allow from all
 </Directory>
</VirtualHost>

Copy the Secure login script below into the /opt/cgi-bin/eprints/ directory (or whatever directory you've set up above); copy the receive data script into eprints' /cgi/ directory.

Finally patch the Apache::Login module of eprints so that everything works smoothly.

Caveats

The login process now works as follows.

1. when a page requires authentication, it creates a "login page" with destination at the secure web site
2. the "login page" is sent encrypted to the secure site
3. the secure site encrypts the payload, and redirects the browser to an unencrypted eprints page receive_data
4. receive_data decrypts the payload, checks credentials, logs in the user if everything checks, and then redirects the browser to the originating page.

What is lost in this process of two redirects is the error message when authentication fails. Receive_data cannot display the error message as its URL should not be displayed on the user's screen. The final page - which is the original one as well - cannot distinguish between an unsuccessful login and a reload, thus cannot display the error message as well. C'est la vie.

The encrypted data the receive_data page receives can be a replay of a sniffed older communication. Thus this data should contain a timestamp and checked to be recent.

The secure site can also check the credentials, and relay the result only. Interestingly, the result should be sent encrypted, as otherwise the secure site could be used as an oracle to tell whether the password is correct or not (ideal for a dictionary attack).

Crypto routines

These routines perform encryption and decryption. It is a lightweight version of more sophisticated ones, but (at least I hope) it is sufficient for this application. After the source there are some remarks for those interested.

Warning! The secret phrase in the second line should be changed to some secret value.

sub _secret { 
  "Whatever is your secret phrase, give anything here"; 
}
sub _intto64 { #a MIME64 type encoding
   my $c=shift;
   $c &=0x3F;
   if($c<10){ return chr(48+$c); }
   if($c<10+26){ return chr($c-10+65); }
   if($c<10+26+26){ return chr($c-10-26+97); }
   if($c==62){ return '_'; }
   return '-';
}
sub _encode64 { #encoding three bytes to four chars
   my($a,$b,$c)=@_;
   $a &= 0xFF; $b &= 0xFF; $c &= 0xFF;
   return _intto64($a>>2)._intto64(($a<<4)|($b>>4)).
      _intto64(($b<<2)|($c>>6))._intto64($c);
}
sub _from64 { #decoding of the above
   my $c=ord(shift||"0");
   if($c==95){ return 62;}
   if($c==45){ return 63;}
   if($c<48+10){ return $c-48; }
   if($c<65+26){ return $c-65+10; }
   return $c-97+10+26;
}
sub _decode64 { # decoding four chars to three bytes
   my($s)=shift;
   my ($r1,$r2,$r3,$r4)=(
      _from64($s),_from64(substr($s,1)),
      _from64(substr($s,2)),_from64(substr($s,3)));
   return ($r1<<18)|($r2<<12)|($r3<<6)|$r4;
}
sub _EncodeValue { ## encoded value should not end in a space
   my($id) = @_;
   use Digest::MD5;
   my $salt=substr(Digest::MD5::md5_hex($id, _secret()),0,8);
   my $sstr=Digest::MD5::md5($salt, _secret());
   my $seed=0; my $ssid="";
   for(my $i=0;$i<8;$i++){$seed=($seed<<8)+ord(substr($sstr,$i));}
   srand($seed); my $idlen=length($id);
   $id .= "  "; # pad message by spaces
   for(my $i=0;$i<$idlen;$i+=3){
      #encode $id[0],$id[1],$id[2] as 4 chars
      my $v=rand(0x1000000);
      $ssid .= _encode64(ord(substr($id,$i))^($v>>16),
                         ord(substr($id,$i+1))^($v>>8),
                         ord(substr($id,$i+2))^$v);
   }
   return $salt.$ssid;
}
sub _DecodeValue {
   my($s)=@_;
   use Digest::MD5;
   my($salt,$ssid)=(substr($s,0,8),substr($s,8));
   my $sstr=Digest::MD5::md5($salt, _secret());
   my $seed=0;
   for(my $i=0;$i<8;$i++){$seed=($seed<<8)+ord(substr($sstr,$i));}
   srand($seed);
   my $id="";
   for(my $i=0;$i<length($ssid)-3;$i+=4){
       #decode next four chars
       my $v=rand(0x1000000)^_decode64(substr($ssid,$i));
       $id .= chr($v>>16) . chr(0xff&($v>>8)) . chr(0xff&$v);
   }
   $id =~ s/ +$//; ## strip spaces at the end
   # $salt and $chksum should be equal
   $id="" if ($salt ne substr(Digest::MD5::md5_hex($id, _secret()),0,8));
   return $id;
}

Remarks:

• The MIME64-like encoding uses letters (both lower and upper case), digits and the characters - (minus) and _ (underscore). These are safe to use in an URL.
• Both encoding and decoding uses MD5 as the building block. The first eight characters of the ciphertext (encoded string) is used for two purposes. First, it acts as a salt, namely it is added to the secret phrase to derive the seed of the random number generator; second it is used to check message integrity, namely it should match the MD5 hash of the message and the secret phrase.
• Messages to be encrypted (plaintext) should not end by a space (spaces are used to pad the plaintext to have length divisible by three)
• The encryption is deterministic. Such a scheme is insecure in general. In our case, however, the plaintext contains a timestamp, thus - supposedly - the same message is not encrypted twice.
• Weak points of the scheme: only 32 bit MAC (and seed) value, and relying on perl's pseudorandom function.