Re-using Raven's password database

Raven currently works reasonably well as an authentication system for interactive, web-based applications. It is however fairly useless for non-interactive or non-web purposes, and this covers a multitude of potential uses: Windows/MacOS/Unix logon, IMAP, POP, SMTP, LDAP, WebDAV, etc., etc. This paper explores the options for a more general purpose solution. In reading it, you should consider what security properties you'd actually want out of such a system, and consider which out of the options presented below could provide that.

Option the first: forget passwords

We could just forget passwords and just 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 Raven 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.

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

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

We could maintain a central collection of passwords, one for each user, and then distribute this list to every system using the service. 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. This largely avoids the problem of users lying and for most users means that they can only authenticate as themselves and only then if they know their password.

But anyone with access to the list can still authenticate as any user on any system using the service, so we'd have to trust all of them not to do so. This obviously includes all of the operators of all the systems using the service so we'd probably have to restrict, though it's unclear on what basis, who we made this available to. Even if we could somehow restrict direct access to the list who wouldn't misuse it themselves, there is still the danger of them accidentally or recklessly allowing 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 using this service still depends on a whole group of people that the particular system's administrator has no particular reason to trust.

The situation is in fact worse, 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.

Option the fivth: Kerberos (or similar)

---to be continied---