Re-using Raven's password database

Raven currently provides a reasonable authentication system for interactive, web-based applications but doesn't support non-interactive or non-web services and this covers a multitude of potential uses: Windows/MacOS/Unix logon, IMAP, POP, SMTP, LDAP, WebDAV, etc., etc. Since Raven of necessity has a database containing username/password pairs for most people in the University, and most people know their Raven password, it is tempting to assume that extending it to support these other uses owuld be simple.

This paper explores various ways in which password-based authentication could be provided and attempts to point out the advantages and drawbacks of each proposal. In reading this, it is useful to consider what security properties such a system should provide. It's also useful to consider who might be attempting to attach what: are we talking about a) a bored University student, b) a tabloid journalist, c) an organised criminal, or d) the American NSA, and are they trying to gain access to a) their mate's photo archive, b) the next heir to the thrown's email account, c) the University financial system, or d) anything else.

Option the first: forget passwords

We could just forget passwords and simply ask people to tell us what their CRSid was. This would even simplify Raven itself:

Doing this would save people from having to remember their password, and would save the CS from having to issue them. Both of these would be significant advantages. Anyone can easily set up almost any system 'protected' in this way - the hard part might actually be stopping it from asking for a password.

The obvious downside is that we'd have to trust everyone in the entire world not to lie, which is rather unrealistic.

Option the second: use a single fixed password

Rather than forgetting passwords completely, we could could use a single, fixed, 'well known' password to protect all accounts.

This would be easy to remember (and easy to recover if you forgot it). It's also fairly easy to set up a system protected in this way.

The problem is that we'd still have to trust everyone who knew the password not to lie. It's fair to assume that a 'secret' known by 40,000 (and rising) people would not stay a secret for long so we'd have to trust quite a lot of people not to lie. It would also be next to impossible ever to change this password. Again this is probably not a realistic option (though this doesn't actually stop people using this as an authentication 'solution', though usually on a small scale - think of the PIN used to are and disarm most intruder alarm systems).

Option the third: distribute a list of username/password pairs

We could modify Raven so that we could extract a list of usernames and plain text passwords, one for each user, and then distribute this list to every system that needed to authenticate users.

Users would quote their username and password, the system could look up the the username and compare the offered password with the one on the list - if it matches they get in, if not they don't. Making use of this information to implement authentication would be fairly easy, and system administrators could post-process the information into whatever form their system actually needed.

This largely avoids the problem of having to trust potential users not to lie - most users will only be able to authenticate as themselves and only then if they know their password. It's still possible for users to give away their password, but that's a feature of password-based authentication.

But the list itself is another matter. Anyone with access to the list can authenticate as any user on any system using this authentication service, so we'd still have to trust all of them not to do so. All of the operators of all the systems using the authentication service would inherently have access so we'd probably have to restrict, though its not clear on what basis, who could use the authentication service. Even if we could somehow effectively restrict direct access to the list to people who could be trusted not to misuse it themselves, there is still the danger that they might accidentally or recklessly allow it to leak to others (from a hacked server, on a laptop sold on eBay, on a memory stick left on a train, etc.). So the security of any one system under this model still depends on a whole group of people that the individual system's administrator has no particular reason to trust.

The situation is in fact worse than presented above, because many people use the same password on more than one system, so anyone with access to the list might find that they can authenticate as other users on systems that don't even use the central service. This and some other failings can be mitigated by distributing non-reversibly encrypted (or hashed) copies of the passwords rather than the passwords themselves. However hashed passwords are vulnerable to dictionary attack, especially when the underlying password is badly chosen as many will be. There are also a number of authentication schemes, mainly those using challenge-response techniques, that require access to the plain text of the password or specialised hash thereof if they are to work.

Option the fivth: Kerberos (or similar)

---to be continied---