Security is one place where the world of computation interacts with the physical world. Nothing proves this better than the fact that most security breaches in connection with computers are based on ”social engineering” rather than flaws in encryption, access control or authentication algorithms. Hence, our first step in understanding authentication must be to understand the context in which authentication takes place. We will then examine the different mechanisms by which authentication is achieved and finally we will see how authentication can be translated into access and authorisation.
Let me begin with a statement:
In order to authenticate we must first grant anonymous access to a certain resource which has an immutable attribute. Authentication is the process of identifying the entity that has obtained access to this resource.
To justify this let us begin in the “distant” past when the only way in which multi-tasking multi-user systems were used was via terminals that were permanently attached to the computer. These terminals were placed in individual offices of the users. At this point authentication was not required since one could assume that only person with access to a specific office was a specific user. The user was identified by the resource she made use of. In this case the resource and its immutable attribute is the terminal which is an input/output device for the computer. The entity is identified by the physical access that the user has to the resource.
So what happens when user B walks into this user A’s office and wants to use the computer from there? The solution is to introduce the username: prompt. Each terminal has a reset button. When this button is pressed the computer prompts the user to supply a name and then authenticates the user by the name supplied.
In this case the identification was based on the trust of the individual whose office is used by the second user; the system did not even ask for a password. However, when multi-user systems had terminals in public access areas passwords were required; at this point access to the terminal had truly become anonymous and thus some form of computer-based authentication was required.
Note that even in this case the computer had no control over the data that was flowing in via this terminal even before authentication had been performed. Thus the program login that monitored the logins had to handle this incoming data carefully otherwise there could be buffer overflow attacks, denial of service attacks and so on. Handling “tainted” data—data from an unauthenticated source—is an important facet of all programs that deal with anonymous entities; e. g. authentication programs.
With network connectivity came the possibility of the terminal not being attached to the computer directly but over an external wire. The immutable attribute that was algorithmically authenticated was now limited to a serial port. As usual, one must assume that the physical equipment—in this case the wire—was inviolable.
However, in practice it could be tapped or spliced. This became more serious when packet-switched networks were used in place of the external wire. The terminal oriented connection protocol or TCP was designed to provide an immutable attribute called a TCP socket. In this case establishing a TCP connection involved the creation of a software “socket” which is represented as a pair of pairs, where the pair consists of a hostid and a port. The authentication process then authenticates the socket.
However, this creation of a socket out of a packet-switched network protocol (IP) is quite problem-ridden and requires its own host-authentication methods. In the past, simple host-authentication methods using IP addresses were considered sufficient. Nowadays there is a move towards securing the networks using SSL, IPSec or more general authentication techniques present in IPv6. In this case, there is low-level authentication via session-keys and other mechanisms that permeates the entire transaction in a manner that is mostly invisible to the user. Such tecniques make use of immutable attributes that are mostly software; but one may ask “Can one really make something immutable out of software?” That we can is the legend of cryptographic authentication.
As explained above the first authentication mechanism used is the just a “username” or IP address. Since the external entity provides this information at the time that it acquires anonymous access, it may or may not be reliable for identification depending on the physical context. So it is common to require additional proof. One of the standard mechanisms used is a password.
In the older contexts where the possibility of wire tapping or wire splicing was remote, such a password would be transmitted “in the clear” over the network. Nowadays, that is not considered particularly secure unless the channel is secured in some way. However, securing the channel requires some other authentication in order to prevent monkey-in-the-middle attacks. In either case we need to consider some form of authentication that does not involve the clear transmission of the password.
In spite of this, a number of systems around the world still use password-based authentication or something similar—like requiring the user to present a credit-card number or date of birth. Other than wire-tapping and replay attacks, this has other vulnerabilities. For example, user’s often have the same password on all systems; if the “password” is biometric then this may not even be the user’s choice! The information is “given away” by the user to the authenticating system—but not all systems that wish to authenticate you are reliable; e. g. we have seen a spate of “phishing” attacks. So what are the replacements for password based systems?
One way is to use a different password each time. In a “one-time-password” system a password can only be used once. The obvious difficulty with this system is how the user and the system decide on the sequence or list of passwords to be used. Another difficulty is that if the user does not verify the system that requests the password so this is still susceptible to “phishing” and monkey-in-the-middle even though the damage may be limited to one session. One significant advantage of this system is that the user is not required to do any computations unlike the systems being discussed below.
One way to generate the list of one-time-passwords is to use a secret generating secret. This second secret must be shared between the user and the service provider so we have “shared secret” systems. In this case the authenticating system and the user have a shared secret. This secret can also be used to create some kind of time-stamped token which is exchanged as proof of possession of the shared secret; the actual secret is never exchanged across the wire. For example, we could take a cryptographic hash function and apply it to the concatenation of the current time, the local address and the shared secret; each party sends its own version of this across the wire. In such a system both the user and the system are sure of the identity of the other party (assuming the invulnerability of the cryptosystem used). One vulnerability is at the point where the shared secret is created and stored by the user and the system. Another vulnerability is due to the fact that today’s user must interact with a number of different systems and so must keep a shared secret with each of these systems; the larger the amount of secret material to be stored the greater its vulnerability.
An alternative is the public-key system. Each user and each system that participate in the protocol publish the public-key component of a private-public pair. The cryptographic invulnerability of the cryptosystem will mean that only the entity which generated the public key can have the private key—unless that entity is compromised. Each party uses the private key to attach a “digital signature” to a the concatenation of the current time and the local socket address; the other party can then verify the signature and thus authenticate the other party. A major vulnerability of this system is the difficulty of verifying that the public-key actually belongs to the entity whom one wants to authorise. Usually public-keys are exchanged at a “key-signing party” or via a tree or web of trust in order to circumvent this problem. Another vulnerability of this system is the requirement of significant computational resources for the creation and verification of digital signatures; this can be used to initiate a denial of service attack.
One way around this computational requirement is the “trusted third party” authentication system. In this case, there is a separate entity that everyone trusts and has significant computational resources dedicated to providing others with authentication information. An elaborate protocol called “Kerberos” has been developed that explains how a session may be securely initiated between parties who are individually known to this Authenticator. Each party expends some computational resources in obtaining recognition from the Authenticator but does not need to spend significant computational resources thereafter.
Once an input resource like a socket is authenticated then all data that comes in from that socket can be marked as coming from that particular authenticated source. The login application that we started with makes essentially only this use of the authentication. However, off late numerous other applications also make use of authentication; e. g. web servers. In all such cases it is important to distinguish between authentication and authorisation.
The process that carries out the authentication transaction does not need to have access to too many system resources; in the case of password-based system it needs to have access only to the appropriate form of the password database. Thus the authenticator need not be a privileged process and can run with low privileges. In particular, compromise of the authenticator does not automatically grant access at all levels; all such a compromise can achieve is fake authentication.
On the other hand a process can only grant access to resources that it too has access to. Thus the authorising process must have very wide access to the system. For example, the login process must run with “root” privileges after it has authenticated the user and is creating a shell process for a particular user. In a typical scenario, an application runs a number of sub-processes at lower privilege; one of these is the authentication process and the rest are authenticated processes. The latter processes run with the privilege level of the user who has been authorised by the authentication process. It is ideal if the top-level of the application limits its “job” to the creation of these processes as that simplifies its security analysis. Since this top-level is the authorising process, its compromise would lead to a wide-ranging compromise of the system.
In practise one sees that monolithic programming is the norm and the kind of privilege separation that is recommended above is only slowly making its way into application programming. One can hope that this situation will improve as the different roles of authentication and authorisation become clearer to programmers.