MTAS Canned

Finally, the MTAS computer system and selection method for young doctors has been canned. But there's going to be something of a rumble over this:

She added that intensive security checks had been made of the website and the MTAS computer system, allowing it to reopen partially. A report was being sent to the police and Miss Hewitt admitted that "criminal offences may have been committed".

Indeed, criminal offenses may have been committed. In fact, I'd say it's very much an odds on certainty.

Firstly, there's the design of that computer system itself. I asked someone who actually knows about such things (Mr. Gillies, thank you) to comment. It's long so it's below the fold but essentially, the second fault uncovered was a result of a grossly incompetent design of the basic system (no, not a result of hacking or anything else). The sort of thing that kiddie script hackers learn about in week two of the course. As he says, this is almost certainly a level of stupidity which is actionable under the Data Protection Act.

But while we giggle at the idea of a government department prosecuting itself for gross dereliction of duty we also know that responsibility of this type is not in fact a feature of our current system. No one gets fired for wasting the taxpayer's money now, do they?

No, the criminal offenses they'll go after are the ones committed that afternoon as this security breach came to light. For anyone who deliberately accessed the system to check and see if they had indeed done somthing so mind-bogglingly stupid were guilty of hacking a computer system, were they not? Deliberately hacking a computer system in fact. And anyone who asked people to check the system, again, to see whether said system was indeed so mind-bogglingly stupid as to work in this manner, was and is guilty of incitement to hack a computer system.

So we have the (I believe a reference to Kafka is obligatory here) situation whereby a grossly incompetent, almost certainly law breaking, computer system is online but anyone who checks that it is indeed lawbreaking and/or incompetently put together is guilty of an offense.

Even if they're checking it so as to warn the authorities that it is open to serious security breaches. As indeed did happen, the system being taken off line less than an hour after the warning was given.

And so are we ruled. The government can be incompetent, but proving that it is is a criminal offense.   

You have to understand the desiderata behind a web-based IT system
like MTAS. There are two mutually-antagonistic features in any such
system. Firstly, the great thing about web-based systems is that they
are view-anywhere. You don't need to download any special software,
and any authorised user should be able to enter the system from any
location. Secondly, only authorised users should be able to enter the
system, These pull in different directions.

The typical way that these are reconciled is via a
username/password-based login. The server on which the system is
running checks the login credentials of the user, and if they match,
permits entry into the system. But how does the system prevent
unauthorised access? And what went wrong with MTAS?

To answer the second question first, the MTAS system made no attempt
AT ALL to ensure that users trying to retrieve information from the
system had successfully logged in. This is evinced by the fact that
the same URL could be used to access data whether or not the user was
logged into the site, and from any location, whether or not a
successful attempt to login had been made from that machine before.

So, how should it have been implemented? The usual method is via a
mechanism known as a 'login session'. On successful login, the server
creates a token. This token will be a cryptographic encapsulation of
the user's access details. The token will be stored in a database,
along with other information, such as a timestamp. The token will also
be passed back to the user, along with a one-time login ID, via some
mechanism (usually either a browser cookie or by rewriting the URL).
So the home page URL might look like http://www.mtas.gov.uk, but
inside the site, URLs might look something like
https://www.mtas.gov.uk/fetch_record.php?recordid=NQBRS297T&loginid=14236&userid=834&ltoken=97CBBB90DD03A671E478E7EA5AAB7A68

The token would be formed by taking the login details (including the
IP address of the machine accessing the site), concatenating them with
a piece of random data, and then running this through a
cryptographically-secure hash function. Secure hash functions have the
property that given a piece of plaintext, it is very easy to generate
a hash, but given a hash, it is computationally infeasible to recover
the plaintext. So spoofing the token is hard (assuming correct
implementation).

Now, every time the user accesses a page inside the site, the token is
passed back in, along with the one-time login ID and the user's
credentials. The login ID retrieves the stored token from the database
and a) makes sure it matches the user's credentials and b) matches the
token passed from the user's browser. If either do not match then the
login session is terminated, the user is kicked out and probably a
warning is sent to a sysadmin. The code to do this is a few dozen
lines at the outside, and any competent web designer should know how
to do this.

If you don't implement a system like this you run afoul of the problem
that MTAS had. But even if you do have a system like this, there are
potential weaknesses. They lead to a problem known as 'session
hijacking'. This is where a third party uses a previous, verified
login session to gain unauthorised access. Sessions should be tied to
a particular machine. Every time a browser accesses a website, it
sends its IP address. This should be stored in the login details in
the database so that an attacker can't cut and paste a URL from one
user's machine and use it on his own. There should also be the ability
to log out at the end of a session, which will destroy or deactivate
the login record in the DB and prevent its being used again. Finally,
login sessions should be deactivated after a period of inactivity.

NONE of these precautions was taken with MTAS. Access to data was as
unencumbered as a link to an entry on your blog. There is NO WAY that
this was anything other than gross incompetence. It is inconceivable
that MTAS had a working login session mechanism that was then replaced
by the brain-dead
version it had when the security breaches came to light. If you're
creating a web-based IT project, just about the first thing you do is
design the security model. This is a level of stupidity that is quite
likely actionable under data protection statutes (implementers of
systems containing personal information have a statutory duty, I
believe, to ensure only authorised persons have access to that data).