Secure login

From EPrints Documentation
Jump to: navigation, search

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).

Secure login script

Receive data script

Crypto routines

Patching Apache::Login