Digital Certificate Operation in a Complex Environment
homebackgroundprojectdocumentsdesignglossary
navigation search
search query:

PKI Primer and Project Background

9. Other authentication methodologies

There are other methods of authentication. These include the most common method of supplying user names and passwords. However, there are a few problems with using passwords. Some of these could be summarised as follows:

  • An 'average' user can never be sure that his password will not be transferred 'in the clear' for anyone listening in to pick up and learn.
  • With the increase in computing power, passwords can be 'cracked' by checking easily remembered passwords against a dictionary of common passwords and English words and combinations.
  • Password databases are often not protected very well and run the risk of being 'hacked' and 'cracked'.
  • Most users choose weak passwords, or they write them down and they often lose or forget them.
  • A different password has to be used for every service that the user accesses, thus leading to the problem of users employing the same password for access to their 'favourite films' web site, workplace network and on-line banking. One of these is likely to be insecure, and once one password is compromised, an attacker can access all of these resources.
  • And there are many more...

There are other, much more secure, authentication mechanisms. However, the level of security attained varies between the methodologies and also in the way that each real-world implementation is carried-out.

*Readers who are only interested in digital certificates and have less interest in alternative authentication methodologies could skip this section and continue with Practical challenges for PKI, below.

Four examples of alternative authentication methodologies are given here, but there are plenty of other examples:

  • one-time passwords
  • challenge-response methods
  • kerberos
  • public/private key systems (outside PKI)

A one-time password system is one way of solving the problem of transmitting passwords over the network. The user is supplied with a list of passwords or a device that generates them on demand (such as a mini calculator-style key ring device). Each of these passwords is only used once. However, users may still lose their password lists or the device may be stolen, and some of the other password related problems (described above) may also remain.

Challenge-response methods are designed to avoid transmitting any password over a network. The server sends a random number to the client (challenge). The client encrypts this number with her password. If (and only if) she supplies the correct password (which never leaves her computer), then the decrypted random number is matched on the server and she is successfully authenticated. Therefore, the problem of passwords being sent over the network is solved, but the other problems listed above are still as prevalent.

Kerberos relies on symmetric key encryption to authenticate users, hosts and services (called principals). To do this, each of these principals shares a secret with a central Key Distribution Center (KDC). Principals can securely authenticate each other via this KDC. Passwords are transmitted in an encrypted form, and the user has only to remember a single password to access all services mediated by the KDC. Therefore, a kerberos based system may protect users from sending passwords in the clear, but the problems of weak passwords, users writing these down (and losing them) and hackers accessing the server's password files still exist.

Public/private key systems simply use asymmetric public and private keys for authentication. There are no digital certificates. However, there are some obvious similarities to PKI systems in that these key pairs form the basis of the authentication mechanisms. In these systems, the server holds a database* of public keys and, when the user connects, the server sends him a randomly-generated challenge that has been encrypted using his public key. On the client machine, he de-crypts this challenge and sends it back. If the challenge is validated (i.e. is the same before and afterwards), the user is positively authenticated and allowed 'in' to the system or service.

* NOTE: The 'database' is usually as simple as simply having a file near each user's home directory that contains each public key but it could theoretically comprise a more sophisticated management system such as a relational database or LDAP server.

It should be noted that all that the user will probably 'see' is a prompt for him to enter his password or pass phrase to unlock his private key. If he types this correctly, he is authenticated at the server. It is possible to leave the private key unprotected without a password or phrase, but this is usually discouraged, as anyone gaining access to his desktop machine will be able to access the server or protected service very easily.

The advantages to this system are that there are no passwords sent over the network. It is very secure in this sense, and any 'attack' has to be done via the users desktop computer (as the public key on the server is seen as too difficult to crack as technology stands at the moment). There should be no danger of an attacker gaining access to services by masquerading as the user without first gaining access to the user's private key on his PC and either stealing or cracking the pass word or phrase. This should lead to a more secure overall 'system' of security than obtained through the other methodologies.

Nevertheless, as there is a danger of an attacker gaining access to the user's desktop machine, then the problems of easily guessed passwords, users writing them down etc. still exist. These problems are not alleviated by the use of public/private keys in 'full-blown' PKI (with digital certificates), either, so the issues of mobility between desktop machines, carrying around private key and password/phrase are very similar to those challenges within PKI.

One advantage that PKI has over a (simple) public/private key authentication system is that certificates (in PKI) are usually set to expire within a reasonable time scale. They should be useless after the expiry date. When public/private keys are used without certificates, the system administrator (of the server or service) has to monitor all of the users and public keys and remove them when the user should no longer have access to the server or service.

9.1. The general rule of security vs. complexity

The following graphic gives a sketch-based summary of these methodologies and their (perceived) flaws or limitations.

Graph of security vs. complexity

This depiction, of increasing security against complexity, may be seen as controversial as there are a variety of ways of implementing each general 'methodology'. The top and bottom of each 'block' for each methodology depict the arguable maximum and minimum level of security that can be attained by a set-up that could be given the title of that methodology. Similarly, the spread left and right depicts the breadth of complexity of each methodology. One interesting aspect to note is that, PKI - despite its relative complexity and potential high security - can be implemented such that it has a lower security level than Kerberos, most 'One-time passwords' and some 'challenge-response' implementations. However, potentially, it has the highest level of security attainable by an authentication mechanism.

Some general points should be made at the end of such a discussion. Often increasing complexity, unless shielded from the end user, can lead to much user dissatisfaction. This, in turn, can lead users to bypass some aspect of the security 'system', thereby bringing down the whole trustworthy system. (An example of this may be PKI users sharing certificates and private keys, or maybe leaving these on a shared network drive). Thankfully, as in Kerberos and probably in future PKI implementations, it is (or should be) possible to shield the end user from this complexity.

Up: Contents Previous: 8. Public key infrastructure Next: 10. Practical challenges for PKI

Oxford University Computing Services Mimas Athens access management services Oxfore e-Science Centre Systems and Electronic Resources Service Joint Information Systems Committee