Author image Michael De La Rue


link-authorisation - how to handle authorisation in LinkController


Using link-controller in an environment with high controlled authentication is inherently a security issue. This risk may, however, not be much higher than the one that you are currently carrying, so this can be useful

This page describes how this works.


The fundamental security problem with this system is that the authentication token must be stored somewhere where the program can access it. This is because link-controller has to send the actual authentication token over the link to authenticate. Since it's very easy to monitor the inputs and outputs of a program, it's very easy to monitor this password.

This applies even if we keep the password in some encrypted form, since we then have to store the decryption key in the program which can then be found and used to decrypt the key.

So there are only two possible defenses:

  • make sure that the program data remains secret

  • make sure that the passwords the program has can't do any real damage

We demand permissions on our files which protect against accidental disclosure by encouraging the user to be more secure.

Making sure that the program can't do any damage is normally achieved by giving it a dedicated account which has only read only privilages and, preferably, can only use it's privilages from a specified IP address which will be the host on which the link checking is run.

Accidental Sending of Tokens

Another authentication risk is that the system will send it to a server which is trying to trick it. This is again difficult to protect against. The only solution in this case is to ensure that the regular expression used for limiting the URI matches only host names which are under the control of the body responsible for handing out the authentication token.

Sending of Tokens over Insecure protocols

If an insecure protocol like HTTP is used for sending an authentication token, then it is possible for someone to listen to the transaction and record the token for later use.

The protection against this is to switch over to only using secure tokens and hard wire the protocol name into the URI regular expression.


Regexp and a Relm token, separated by whitespace.

  # comment
  <uri-regexp> <authentication-token> <realm-regexp>

The location of this file is determined by the $::authfile configuration variable.

The authentication token is `encrypted' with the rot13 (Caesar) scheme. This is not a security measure as such. Rather it allows those who don't want to know the password to read the file but not directly see the passwords.

At startup, test-link reads in the file. Whenever a document needing authentication is